Automation of acceptance testing of Selenium + .NET Web Api + AngularJs

I will tell you how we in the company work with acceptance tests. In the article you will find a link to the repository with the code and video with the example of work.

Not all tests are equally useful.

Some time ago, the dispute was relevant - “Should a developer test his code?”. Yes, the developer should test what he creates. I think that now with this statement very few people will argue.

The next question was - “How should a developer test his code?”. The answer to this question was found - TDD. In an ideal world, the developer develops most of the functionality through tests. As a result, we get a good design of the code, which is convenient to maintain and modify, plus a set of test cases that allow the developer to calmly make changes to the existing code.

It happens in a perfect world. In fact, it does not always work out all the development through testing. Even if all development is done using TDD, we still can’t say that the system being developed will start to work properly at the customer.
')
Unit tests do not affect the environment - if you need to test a service that appeals to the database for data, the developer writes a stub for the database. If you need to check the service that accesses the external service, the developer writes a stub that emulates the work of this service.

The next step is the configuration and integration tests, which bring into the virtual test environment the physical elements of the system - the database server, hardware firewalls, third-party software. The implementation of such tests allows us to say that the system “correctly” interacts with the environment. But even the “right” interaction with the environment does not guarantee us that the system will eventually work as expected - according to the scenarios that are described in the specification.

As my practice shows, acceptance testing is the most useful test. By acceptance testing, I understand the following:

• Created a test site as close as possible to the configuration of production
• The test site includes the hardware and software component - firewalls, servers, third-party software, etc.
• At this site, tests are performed according to the scenarios, which are specified in the system acceptance test method (hello GOST 34)
• The site checks the main cases for which the user works with the system.

If you manage to raise such a platform (which is often difficult to do), and check all test cases according to specification scenarios, then with high probability we can say that the system is working as expected and as a result does not contain errors.

Of course, there will be errors, but performing acceptance testing makes it more likely (compared to unit testing and integration testing) to detect errors.

Automate acceptance testing

Automation of acceptance testing is reduced to the following steps:

• Write acceptance test scripts
• Develop tests based on Selenium
• Automate the process of running tests for execution after changing the code in the repository

Acceptance Test Scenarios

We write acceptance test scripts in the form of use case scripts in specifications. The specification is developed by the analyst based on functional, user, non-functional and other requirements.

To maintain specifications, we use Atlassian Confluence in conjunction with the Balsamiq Mockups .

Development of tests based on Selenium

To develop tests, we created our own solution, which allows:

• Develop tests based on the PageObject pattern
• Run tests on different browsers
• In case of a test error, receive a screenshot, a copy of html pages and the name of the test case.

The development of new tests is reduced to the description of the test pages - PageObject and the development of test case steps.

The project with acceptance tests looks like this:


Main components:

• Common \ BasePage.cs - base classes for describing PageObject pages. Contains helper methods for finding items on a page using various selectors.
• Common \ BaseTest.cs is the base class for all acceptance tests. Contains the logic of starting / stopping browsers to perform tests, the logic of waiting for the completion of all active $ http client application requests.
• PageObjects - the directory contains the description of the client application pages. The Page Object page encapsulates knowledge about page elements and actions that can be performed on a page.
• TestCases Directory - contains cases for running tests

The test consists of steps - Step (). A step can perform an action and check the execution of some statement. The following is an example test:

• Open the login page
• Login as administrator
• Open report
• Lock Report
• Edit two cells "110" and "220"
• Save changes
• Unlock report
• Make sure that in the cell "GOU" the sum was calculated on the entered values ​​- "110" + "220"

Test code:


The video shows the test.


If an error occurred during the test - the authorization failed, the report did not open, etc., then a screenshot of the page, browser name, test name and html error page will be saved to the directory specified in app.config.

Determining the completion of all $ http requests for an AngularJS application

Client SPA application performs server requests using the $ http service. For example, when you open the “Daily report” report, an asynchronous call to the server is performed. In response, the client receives report data from the server.

In test scenarios, you must be able to wait for the completion of all requests. For example, after the transition to a report, the client application takes time to download data from the server. After the data is loaded and displayed on the page should be tested this page.

To track the completion of all $ http requests, I use the following approach:

• The client application creates a variable that contains the number of active $ http requests
• The $ http service is injected, which increases the variable by 1 when sending a request and decreases the variable by 1 if the request is successful or unsuccessful.
• Selenium checks the value of this variable to ensure that the client has completed processing the request.

Running Acceptance Tests with TeamCity

As a continuous integration server, we use TeamCity.

After the developer has sent the code to the repository - TeamCity deploys the test site and runs acceptance tests on it. Thus, after each code change, the project is installed and tested from scratch. This solution is a great time saver plus allows us not to think about regression testing.

Basic steps:

• Clear the site directory from the old build
• Configure the app.config of the application - the connection strings are configured from the test database
• Build a project - launch MSBuild
• Stop IIS
• Delete old test database
• Create a new test database
• Copy application files to site directory
• Launch IIS
• Run acceptance tests

Who writes acceptance tests

Acceptance tests can be written either by the developer, upon completion of the script implementation, or by a testing engineer specifically assigned to these tasks.

Source

The source code of the test application is available on github .

Conclusion

Automate acceptance testing can and should be. Advantages of this approach:

• There are guarantees that there is a working code in the repository that will be compiled, installed on the site and will work properly according to the specification scripts.
• The time for manual testing is reduced - the test is written once and executed each time the code changes.
• Reduced regression testing time
• The time for searching and documenting errors is reduced - if the test fails, the playback steps will be recorded in the logs and a screenshot will be attached
• The cost of error correction is reduced - an error found in the office will cost less than an error found at the customer

At the end of the article I will say that for large and long projects that last half a year or more - the presence of automated acceptance tests is a necessary condition for ensuring the required quality of the product.