The review process is a good way to keep your code clear and understandable. It is important both to review others’ code and having your own code reviewed, not depending on how many years you have been working in the project or how much experience you have gotten. This chapter describes several cases when it is important to review or optimize your tests, or vice versa – when it is better to do nothing instead.
5-1. Write Tests That Even Non-Automation Engineers Can Understand
Tests should be well written in order to be easy to maintain and modify, as well as to make it easy for you to find the reasons behind any failures during execution. How then, does one determine if a test is well written or not?
One approach is for the automation engineer writing a test is to show it to a tester who is not familiar with programming. If the tester understands what the test does, then the test is considered to be good.
Achieving clarity is very simple. Simply take care to write each test using function names that speak for themselves. For example:
function test_login(){open_page("http:\mywebsite.org");login_as(login="test user", password="test password");verify_page_opened("Web Site Start Page");}
This code will be understandable even for those who are not familiar with programming . No matter how complicated the internal implementation of the invoked functions is, everything is clear at the top level.
For comparison, record such actions using any automation tool and look at the result. You will get something like the following:
driver = self.driverdriver.get(self.base_url + "/admin/")driver.find_element_by_id("fLogin").clear()driver.find_element_by_id("fLogin").send_keys("[email protected]")driver.find_element_by_name("pass").clear()driver.find_element_by_name("pass").send_keys("MY PASSWORD")driver.find_element_by_css_selector("button.saveButton.okButton").click()
You should admit that this code is not only longer, but also less understandable in comparison with the first version. Automated recording tools will tend to generate code that is unclear and difficult to understand, whereas writing tests with intention allows you to invoke functions having clear names and purposes.
5-2. Avoid Unneeded Optimization
I have seen many times that testers are doing an unnecessary thing: they optimize the speed of a particular function, because it seems to them that it does not work fast enough. Before starting to perform any optimization, you need to make sure it provides benefits that are worth spending time on to optimize your code.
According to the Theory of Constraints, optimization should always begin with the weakest section. In the test automation, this section is usually the application under test. Not always, but often. Optimization of test scripts is often free from providing any benefit.
Of course, you do not need to always use the slowest algorithm if you know another that happens to be faster. And I am not saying that you don’t ever need to optimize. There is a time for optimization.
What I suggest is that you optimize tests in two cases:
If a test runs unreasonably long, and the application under test is idle during the test execution.
If you see an obvious problem in the code, the correction of which doesn’t take much time.
You should always look at the performance of the scripts from the point of view of the whole system (scripts, the application under test, and the environment on which the testing is performed). For this purpose, at the very beginning of the project, it is better to determine the quality criteria that automatic tests should meet (speed of all tests, the frequency of running certain tests, etc.) and follow those criteria .
5-3. Review Someone Else’s Code Regularly
Viewing a new code written by another person is one of the best ways to keep your project in order. As soon as a test and the general functionality necessary for it are written, the code should be looked at by a second person. It is possible during such reviews to find potential errors, or simply to fix incomprehensible or difficult places in the code.
Code written by junior testers must especially be checked. The code of more experienced employees also needs to be reviewed, however, since no one is fail-safe. Sometimes it happens that the author of code for a test has made some assumptions that are incorrect. Other times a developer might mock up some functionality intending to fix it later, but forgets to do it. Reviews can help catch such problems.
There is no need during the review stage to verify whether a test works, since such verification should be made by the author of the test. You only need to view the code itself and pay attention to complex or incomprehensible blocks. To do this, you can make a small list of rules, helping you focus on what to look for when reviewing.
Viewing someone else’s code also has the reverse side: it is quite possible that by reading it you will find something new, a simpler algorithm or approach that you did not know about or just did not use for a while.
Another good example is pair programming, in which one person writes the code, and another one sits nearby and gives advice. Although at first glance it may seem that this approach leads to a loss of time for one of the participants, the overall quality of such code is higher than when one person writes it.
5-4. Participate in Forums and Discussions
If you are a beginner in automation and come to work in an automation team, you will learn a lot from your colleagues. However, it may happen that you are the only automation engineer in the company, or in your department, and there is no one around who to provide advice in a difficult moment. The solution? Help others! There is no better way to speed up your learning.
In these cases, specialized forums dedicated to the automation tool that you use will help you. Many people are limited to just asking questions on such portals; however, answers to questions are the minimum such forums can give you. Of course, you will probably start with a question, and, most likely, you will immediately get an answer, since the questions of newcomers can usually be resolved fairly quickly.
Subscribe to new messages from your forum of choice, and carefully read both questions and the answers to them. In time, you will see that the answers to some questions are clear to you, and that some of the questions you can answer yourself. Once you feel that you know the right answer, feel free to write the answer! The worst thing that can happen is you will be mistaken, you will be corrected by more experienced participants, and you will become even more experienced.
After a while you will be able to answer many questions. If you are not sure of the correctness of a particular answer that you plan to provide, then try it yourself to be sure. Even if you are not sure of the correctness of your own solution, it still makes sense to try to solve a problem by yourself before checking others’ answers.
Such a study on other people’s examples will give you the opportunity to work with those tool options that you might never have encountered at work. For instance, if you are testing only desktop applications, you will never encounter web applications, and your knowledge of the tool will be one-way. If in the future you will go to interview in another company, where they test the web applications, you will be surprised how weak your knowledge is.
On the contrary, if you regularly try to solve other people’s tasks, you will accumulate diverse experience. And once, when faced with a task for the first time, you will know exactly how to solve it, although you have never done anything like this before.
5-5. Perform Refactoring
Refactoring is the simplification of existing code, in which the functionality of the application does not change (and in the case of test automation – the functionality of the tests or common code). Despite the fact that the code in test automation is usually much simpler than in real applications, sometimes you still need to do refactoring.
You may find that the code you are supporting is too complex. This is a good candidate for refactoring.
There may be a request for writing new tests, for which there are already almost suitable common functions and classes. In this case, it is better to make changes to the existing code than to write a new one (probably repeating the same errors as the author of the original code).
Refactoring may be needed to improve the code that was written in a hurry. Such tests can’t be left in the form they were written; it is necessary to immediately plan their modification and bring them to an acceptable form.
Since refactoring should not change the functionality of the tests, it is required to run all the tests that use the modified code immediately after refactoring is done. It is even better to simulate errors in tests to make sure that tests continue to perform those verifications that were performed before refactoring.
Programmers often use unit tests to make sure that changes in code do not affect the results of their work. In test automation, this is not always convenient, because functions and classes can work with screen elements, that is, to verify this code, you will need to run the application under test. However, if you have libraries that don’t depend on GUI elements, you can also use unit tests in your project.
If you are not familiar with refactoring , take any book on this topic and read at least about the basic methods. Most probably you will be using just five to six refactoring methods in your everyday work, so you should master these methods and have a quick look at other ways of refactoring just in case.
5-6. Remove Tests That Provide Minimal Benefit
Imagine that your application under test is actively developing, and you are constantly writing new tests. Over time, the support for existing tests will take more and more time, with less time to write new ones. Then you will have a choice: either significantly reduce the writing of new tests, or delete some of the old ones, the benefits of which are minimal.
The first approach is not suitable. You cannot reduce writing new tests, because you need to try to cover with automated tests as much functionality as possible. Thus, the approach that is left is to remove older tests that are providing minimal benefits.
How do you determine whether a test is useful or not? To do this, it is necessary to keep statistics on each available test as early as possible. Track statistics such as the following:
How many times each test was started;
How many real problems were found by a given test;
How often the test has to be fixed.
In time, you will see that not all tests are equally useful. You will find that some tests are helping you to find more bugs, whereas other tests seem to do little more than use up your valuable time in keeping them maintained.
For instance, some problems are easily detected manually, and therefore they are registered before the corresponding tests are started. It can also happen that several tests verify the same functionality, making one or more of those tests redundant.
In such cases, you can’t just throw off the “most useless” tests. It is necessary to review each such test manually in order to understand the probable cause of its “uselessness”. Only then can you make a decision about its removal, or transfer to manual testing . Try to involve all automation participants in your project in the process, since everyone should feel responsible for the overall work.
It may be difficult for you to delete the results of your own work, but it is better to have 10 tests that can be supported than 50 tests that are generating so many results that you do not have time to figure out the reasons of their fails and correct the situation.