Automated inspection should form an inseparable unit, and one use case can only test one function point. This is very similar to writing unit tests due to the very small granularity of the tests.
An atomic test case should have as
few assertions as possible, usually only one or two assertions.
Tests avoid interacting with the UI interface and can only be done on a maximum of two pages.
In general, the smaller the test granularity. The test cases get more complex, but there are many advantages to designing the tests to be as small as possible.
Writing atomic tests can be executed quickly to get test results. Feedback from test reports is prompt and targeted. The time to check the status of a function is generally within a few seconds.
For the error information in the test report, it will be possible to quickly reproduce and troubleshoot the root cause of the bug, and quickly resolve it.
Shorten the test chain
If the average execution time of a single test case can be shortened by half, the test efficiency will be more than doubled. Because the longer the test time, the greater the possibility of false positives, and the greater the possibility of failure as the interference factors continue to accumulate.
Writing atomic test cases reduces fragility because it reduces the number of possible breaks in that test. Atomic test cases can reduce a large number of false positives, which in turn can improve the time to troubleshoot problems.
An example:
open the home page of a web page;
assert that the page is open;
assert that an element exists;
open a search page;
search for an article;
assert that the article exists;
When using automated testing, each step has a probability of error.
For example, a locator or interaction mechanism may have changed and a synchronization policy may have expired.
So the more steps there are in an automated test case, the more likely the test will break and generate false positives.
Test Coverage
A third benefit of writing atomic tests is that if an atomic test case fails, they will not block the tests of other functional cases.
In other words, automated test cases can conduct a more comprehensive inspection of business functions without worrying that the test chain is broken and subsequent functions cannot be covered.
Refer to the test mentioned above: if you fail in the step assert element existence, you may never be able to check whether the search page or search function is working.
If in a regression test scenario, when running large-scale test cases, atomic test cases will reduce the scope of the test. Another huge benefit of writing atomic test cases is that they will be faster at runtime because parallelization is fully possible.
Web Automation Use Case Split
A simple scenario:
open the homepage of the shopping website;
assert that the page is open;
search for products;
assert that the product has been found;
add to the shopping cart;
assert that the product has been added;
add order information;
checkout;
assert that the order is successful;
Many automation engineers believe that this test case must fully execute the entire test chain process.
For example, it must be before the search must be before the home page must be opened, and so on.
The reason is, how do you get to the checkout process if there are no items in the cart?
Injecting Test Data
The best practice approach to automated testing is to inject data to populate the state of the application before UI interactions.
This will greatly help the testing process.
For example: the state of the application can be controlled through several options:
use the methods of the API testing framework to set the application to a specific state;
use JavaScript to modify the page;
inject data into the database to set the application to a specific state;
use cookie information;
If you can insert data between the seams of your application, you can isolate each step and test it individually.
Some options to consider:
send a network request to generate a new test user;
send a network request to populate the cart with items;
use Selenium to open the browser to the cart page;
use web automation to perform checkout;
clean up all test data afterwards;
Using an HTTP interface
Testing with an API is much more powerful and faster than using an automated GUI at each test step.
For example, an HTTP request can be executed in about tens of milliseconds.
This means that the requirements in the preceding steps take less than a second to complete.
The only step that the test case needs to complete is completing the checkout process using Selenium (the only part that will actually be tested).
Using a JavaScript
login page is one of the most common hurdles in testing, and most apps have to go through this step to get into the system.
So, how to remove it from the test so that the test case can be atomic?
An example:
on a page with a login screen:
use the GUI test tool to open the web application;
execute the JavaScript script;
login successfully;
Now, use the GUI automated testing tool to execute the single atomic test case to be tested.
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive