Shulou(Shulou.com)06/03 Report--

Editor to share with you the vue-cli scaffolding based on Nightwatch example analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

The testing efficiency varies greatly among different companies and organizations. In this era of rich interaction and responsive processing, many organizations use agile ways to develop applications, so test automation has become an essential part of software projects. Test automation means using software tools to run tests in the project over and over again and provide feedback for regression testing.

End-to-end testing is also referred to as E2E (End-To-End test) testing, which is different from unit testing, which focuses on verifying the output of functions. End-to-end testing will simulate the access behavior of real systems from the perspective of users as far as possible. For Web applications, this means opening browsers, loading pages, running JavaScript, and interacting with DOM. In short, the function of unit testing can only ensure the quality of a single component and cannot test whether a specific business process is working properly, while E2E is just the opposite. it is a higher-level integrated test between components and between users and the real environment.

The significance of E2E testing is that it can solidify and simulate user operations through programs. For developers, E2E testing can greatly improve the development efficiency of Web and save development time.

First, let's take a look at the process from development to manual testing without E2E testing:

This process is also simplified and does not include opening the browser's debug window to view some internal running variables or web page code structure when observing the results. The whole process is purely manual, and the biggest problem with manual operation is that a program may have to be debugged several times, and the same operation has to be repeated several times. Even if there are strict rules, programmers mostly casually do "pass" operations, especially when entering sample data, the vast majority of programmers are almost random input, the most common is a variety of random numbers or "aaa", "asd", "aws" such meaningless characters. When a program is developed in this way, the product manager or customer will often say, "there was no problem when I tried it last time!" In the final analysis, such mistakes do not lie in the programmers themselves, because it is a kind of human nature! If a person repeats an action that he or she feels meaningless many times, he or she will avoid doing it, or he will be treated negatively if he cannot avoid it.

So we should deal with it in a more efficient, human-friendly, and meaningful way, which is called E2E testing. Let's take a look at what the development process will look like after using E2E testing:

Everything is automatic from the start of running the test! This is the biggest difference, and more importantly, when we want to write the E2E test, we need to have a deep understanding of the operational requirements, and there is a great opportunity to optimize the user's operation in the process, so as to improve the user experience.

Nightwatch

Vue-cli 's webpack template also provides us with a popular E2E testing framework-Nightwatch.

Nightwatch is a newly developed acceptance testing framework based on Node.js, which uses Selenium WebDriver API to automate the testing of Web applications. It provides simple syntax and supports the use of JavaScript and CSS selectors to write end-to-end tests running on Selenium servers.

The specific workflow of the framework after configuration is shown in the following figure.

Nightwatch uses the Fluent interface pattern (https://en.wikipedia.org/wiki/Fluent_interface) to simplify the writing of end-to-end tests, and the syntax is very concise and easy to understand, as shown in the following code.

This.demoTestGoogle = function (browser) {browser .url ('http://www.google.com') .waitForForElementVisible (' body', 1000) .setValue ('input [type = text]', 'nightwatch') .waitForElementVisible (' btnG [name = btnG]', 1000) .click ('btnG [name = btnG]') .pause (1000) .assert.containsText ('# main', 'ElementVisible) .end ();}

We can find a list of features currently available on the Nightwatch website:

● 's simple but powerful syntax. Developers can write tests very quickly by using JavaScript and CSS selectors. Developers do not have to initialize other objects and classes, they just need to write test specifications.

● has a built-in command line test runner that allows developers to run all tests at the same time-either in groups or individually.

● automatically manages the Selenium server; you can also disable this feature if Selenium is running on another machine.

● supports continuous integration: built-in JUnit XML reports, so developers can integrate their own tests with systems such as Hudson or Teamcity during the build process.

● uses the CSS selector or Xpath to locate and validate elements on the page or execute commands.

● is easy to expand, and it is convenient for developers to implement commands related to their own applications according to their needs.

Configure Nightwatch

To understand the configuration and usage of Nightwatch, like the previous introduction to Mocha, you should start with the engineering structure.

Engineering structure

.

└── test

└── e2e

├── custom-assertions / / Custom assertions

│ └── elementCount.js

├── page-objects / / Page object folder

├── reports / / output reports folder

├── screenshots / / automatic screenshot

├── nightwatch.conf.js / / nightwatch running configuration

├── runner.js / / operator

└── specs / / Test File

└── test.spec.js

The above is the Nightwatch project structure that vue-cli automatically created for us. Specs is the folder where the test files are stored, and nightwatch.conf.js is the running configuration file of Nightwatch. Other catalogs will be described one by one in specific chapters.

Basic configuration

Nightwatch configuration items are concentrated in nightwatch.conf.js, in fact, this configuration can also be a JSON format, using JSON format can simply write some constants to the configuration item. However, configuration using modules can execute some additional configuration code, which makes it more flexible. Here are the contents of the nightwatch.conf.js file that I have adjusted:

Require ('babel-register'); var config = require ('.. /.. / config'); var seleniumServer = require ('selenium-server'); var phantomjs = require (' phantomjs-prebuilt') Module.exports = {"src_folders": ["test/e2e/specs"], "output_folder": "test/e2e/reports", "custom_assertions_path": ["test/e2e/custom-assertions"], "page_objects_path": "test/e2e/page-objects", "selenium": {"start_process": true, "server_path": seleniumServer.path, "port": 4444 "cli_args": {"webdriver.chrome.driver": require ('chromedriver'). Path}}, "test_settings": {"default": {"selenium_port": 4444, "selenium_host": "localhost", "silent": true, launch_url: "http://localhost:" + (process.env.PORT | | config.dev.port)," globals ": {}} Chrome: {"desiredCapabilities": {"browserName": "chrome", "javascriptEnabled": true, "acceptSslCerts": true}}, "firefox": {"desiredCapabilities": {"browserName": "firefox", "javascriptEnabled": true, "acceptSslCerts": true}

The configuration of Nightwatch falls into the following three categories:

Basic configuration of ●

● Selenium configuration

● tests the environment configuration.

All root element configuration items in the configuration module belong to the basic configuration and are used to control the global operation of the Nightwatch. The following table provides a detailed description of the basic configuration items for Nightwatch.

Selenium configuration

Selenium is a set of software tools, and each tool has a different way to support test automation. Most QA engineers using Selenium only focus on one or two tools that best meet the needs of their project. However, learning all the tools will give you more options to solve different types of test automation problems. This set of tools has rich testing functions and fits well with the needs of testing various types of website applications. These operations are very flexible, and there are a variety of options to locate the UI element while comparing the expected test results with the actual behavior. One of the most critical features of Selenium is its support for testing on multi-browser platforms.

Selenium was born in 2004, and when Jason Huggins, who works at ThoughtWorks, was testing an internal application, as a smart guy, he realized that his time should be more valuable than having to test every change manually. He developed a JavaScript library that can drive pages to interact with each other, allowing multiple browsers to automatically return test results. That library eventually became the core of Selenium, the basis for all the functions of Selenium RC (remote control) and Selenium IDE. Selenium RC is groundbreaking because there is no other product that allows you to control the browser in your favorite language.

Selenium is a huge tool, so it has its own shortcomings. Because it uses an JavaScript-based automation engine, and browsers have a lot of security restrictions on JavaScript, some things are difficult to achieve. To make matters worse, web apps are becoming more and more powerful, using a variety of features provided by new browsers, making these restrictions painful. In 2006, Simon Stewart, an engineer at Google, began to develop based on this project, which was named WebDriver. By this time, Google was already a heavy user of Selenium, but test engineers had to circumvent its limitations. Simon needs a test tool that can talk to the browser directly through the browser and the operating system's local method to solve the problem of sandboxing in the JavaScript environment. The goal of the WebDriver project is to address the pain points of Selenium.

Selenium 1 (also known as Selenium RC or Remote Control) Selenium RC was the main Selenium project for a long time until WebDriver and Selenium merged to produce the latest and most powerful Selenium 2. Seleinum 1 is still actively supported (mostly maintenance) and provides features that Selenium 2 may not support in the short term, including support for multiple languages (Java, JavaScript, Ruby, PHP, Python, Perl, and C #) and for most browsers.

Selenium 2, also known as Selenium WebDriver, represents the future direction of the project and is the latest addition to the Selenium toolset. This new automation tool provides a number of amazing features, including a more cohesive and object-oriented API, and overcomes the limitations of older versions. The authors of both Selenium and WebDriver agree that both have their own advantages, and the combination of the two makes the automation tool more robust. Selenium 2. 0 is precisely the product here. It supports WebDriver API and its underlying technology, and also provides great flexibility for porting test code through Selenium 1 technology under WebDriver API. In addition, for backward compatibility, Selenium 2 still uses the Selenium RC interface of Selenium 1.

You can download various stable versions of Selenium from http://selenium-release.storage.googleapis.com/index.html.

If you use vue-cli in a Vue project, Nightwatch will not need any additional configuration, otherwise you will need to install Selenium's wrapper class library on the command line:

$npm I selenium-server-D

Nightwatch can guide the startup of Selenium. In fact, there is no need to modify the default running configuration of the Selenium server. In the nightwatch.conf.js configuration file, you only need to declare the specific path of the binary execution file of the Selenium server, which can be obtained from the path property of the Selenium wrapper object provided by the selenium-server package.

Write the physical path of the machine to the configuration file.

Var seleniumServer = require ('selenium-server'); module.exports= {"selenium": {"start_process": true, "server_path": seleniumServer.path, "port": 4444, "cli_args": {"webdriver.chrome.driver": require (' chromedriver'). Path}}, / /. Omit}

The following is a detailed description of the configuration items for Selenium:

Configuration of cli_args

● webdriver.firefox.profile:Selenium defaults to creating a separate Firefox configuration scheme for each session. If you want to use the new driver configuration, you can declare it here.

● webdriver.chrome.driver:Nightwatch can also use the Chrome browser to load tests, of course, you have to download a ChromeDriver binary runtime to support this. This configuration item is used to indicate where ChromeDriver is installed. In addition, you need to use the desiredCapabilities object to establish a configuration scheme for Chrome within the test_settings configuration.

● webdriver.ie.driver:Nightwatch also supports IE, which works and uses the same as Chrome, which is not dwelt on here.

Test environment configuration

The project in test_settings will be applied to all test instances. In the E2E test, we can obtain these configuration values through the default instance object browser provided by Nightwatch. Vue-cli has created three environment configuration items: default, firefox and chrome for us. Default configuration is the basic configuration option applied to all environments, and other configuration items will automatically override the same configuration values as default.

The two configuration items firefox and chrome describe and configure the drivers of the two browsers. They are also regular customers for other languages or frameworks, but because of their low performance, they are usually just a gadget in practice. Below, I will introduce a more efficient headless browser PhantomJS to replace it.

Don't be fooled by the default configuration created by vue-cli. Test_settings is not just the configuration of some basic running parameters of the browser, its correct use is the configuration of the E2E test environment. Unit testing can only be run in the development environment, while E2E can run in the local environment and network environment, more accurately, the development environment and production environment. So this configuration item can be set in the following ways:

"test_settings": {"default": {"selenium_port": 4444, "selenium_host": "localhost", "silent": true, launch_url: "http://localhost:" + (process.env.PORT | | config.dev.port)," globals ": {}}," dev ": {" desiredCapabilities ": {" chrome "," javascriptEnabled ": true," acceptSslCerts ": true} "production": {"launch_url": "http://www.your-domain.com"" desiredCapabilities ": {" browserName ":" firefox "," javascriptEnabled ": true," acceptSslCerts ": true}

Although only a little change has been made in the use of words with the original configuration, the change in the use of words will completely change our understanding and thinking of it!

The following table is a detailed description of the test environment configuration items:

Perform the E2E test

Vue-cli has configured instructions to run tests in package.json:

$npm run e2e

This directive enables the Chrome runtime environment by default. If you specify the runtime environment, you can use the-- env option:

$npm run e2e-- env

Use the headless browser PhantomJS

The vue-cli webpack scaffolding template is very easy to use, which reduces the complexity of the environment a lot, but does not well explain the reasons and functions of each module used in it, as well as the characteristics of their use. For starters, it is true that the threshold is reduced to a minimum, but from the perspective of engineering development, only knowing the existence of these environments or tools is far from enough. There is such a hole in Nightwatch.

Our development environment already has PhantomJS installed when configuring Mocha and Karma, but if you read the default configuration of Nightwatch, you will be surprised to find that there is no PhantomJS at all, just Chrome and Firefox! What's the problem? One word: slow!

I used a 2013 version of a standard iMac (i5CPU, 8GB memory, 1TB HDD hard drive) to run the sample program in the next chapter of this book, and the actual time to run it at a time is about 15 seconds! It takes 15 seconds just once, so can you imagine at least how many times we have to run a scenario? Chrome starts very slowly, and we do automated tests like E2E if we use a real browser.

Can only drag down the performance, life can not be spent in meaningless waiting! That's why we chose PhantomJS! Not configuring PhantomJS as the main browser by default is the biggest failure of this environment.

There are always more ways than problems, so if not, we can still configure it ourselves, in fact, the method is also very simple. Open nightwatch.conf.js and add the following below the test_settings configuration section:

"test_settings": {"default": {/ /...}}, "phantom": {"desiredCapabilities": {"browserName": "phantomjs", "javascriptEnabled": true, "acceptSslCerts": true, "phantomjs.page.settings.userAgent": "Mozilla/5.0 (Macintosh) Intel MacOS X 10 / 10 / 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36 "," phantomjs.binary.path ":" node_modules/phantomjs-prebuilt/bin/phantomjs "}}

Nightwatch loads a GhostDriver through Selenium to boot the PhantomJS browser, which is equivalent to telling Selenium to load a GhostDriver, and the executable program points to the phantomjs-prebuilt package installed on npm, and then uses this package to boot the PhantomJS installed on the local machine.

The address of the binary that references PhantomJS as above is very ugly, and the address of the Selenium executor in the native configuration is the same. Here is a more DRY way to deal with these paths:

Var seleniumServer = require ('selenium-server'); var phantomjs = require (' phantomjs-prebuilt'); module.exports = {/ /. Omit "selenium": {/ /. Omit "server_path": seleniumServer.path,}, "test_settings": {/ /. Omit "phantom": {"desiredCapabilities": {/ /. Omit "phantomjs.binary.path": phantomjs.path}} / /. Omit}}

After doing this simple optimization, you can open the runner.js file to find:

If (opts.indexOf ('--env') =-1) {opts = opts.concat (['--env', 'chrome'])}

Just change chrome to phantom:

If (opts.indexOf ('--env') =-1) {opts = opts.concat (['--env', 'phantom'])}

Reload the test program, the running speed on the same iMac dropped directly to 5 seconds, and the test running speed was increased by 3 times! If you have a better configured machine, you will have more amazing speed when you replace the hard drive with SSD.

Nightwatch and Cucumber

If the business complexity of the project you are developing is small, you can directly use the chained invocation method recommended by Nightwatch. But when this practice is really applied to application scenarios where there are many business processes or relatively complex business operations, you will feel that there are always endless E2E tests, because there is no way to cover all the requirements at once!

E2E testing is actually an implementation method of behavioral-driven development. If you skip the analysis part of behavioral-driven development and write E2E directly, the result can only be a bunch of seriously fragmented test scenarios, and even a lot of operations that should not occur at all.

Fortunately, Nightwatch has good scalability and compatibility, and can integrate the most orthodox BDD testing framework, Cucumber (https://cucumber.io/). Cucumber is a BDD framework originally from the Ruby world, but it also has many language implementation versions. We can install a set of Cucumber version written specifically for Nightwatch-nightwatch-cucumber (https://github.com/mucsi96/nightwatch-cucumber). This chapter only deals with the configuration of the environment and tools, but how to apply BDD is beyond the scope of this book. If you are interested, you can refer to the chapter on Behavioral driven Development in the book climbing to the Top of Architecture.

$npm I nightwatch-cucumber-D

Then add the configuration of Cucumber to the ~ / test/e2e/nightwatch.conf.js file:

/ /... Omit require ('babel-register'); require (' nightwatch-cucumber') ({nightwatchClientAsParameter: true, featureFiles: ['test/e2e/features'], stepDefinitions: [' test/e2e/features/step_definitions'], jsonReport: 'test/e2e/reports/cucumber.json', htmlReport:' test/e2e/reports/cucumber.html', openReport: false}) The above is all the content of the article "Nightwatch-based sample Analysis of vue-cli Scaffold". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.