Better Test Code Principles: #6 Don't create a new variable for a value you will only use once

If you are an automation tester, you will need to write a lot of code to cover the required test scenarios and test cases. Your code base will grow and grow, but some of the code will not be really needed and thorough code reviews should be done, to avoid unnecessary code.

Such unneeded code might include forgotten and unused imports, duplicate code that should have been extracted in a separate method or variables that are declared only to be used in one place.

Such variables may hold anything from a simple String, to the result of computing a complex expression that leads to an integer value. The most frequent usage of such a variable that I have observed in tests is as the expected or the actual value from an assertion method. For example, you might have something like this in your tests:

String expectedString = “This is the expected String”;
assertEquals(someVariable, expectedString); 

You first declare the ‘expectedString’ variable, initializing it with the ‘This is the expected String’ value. Then, you use it as a member of the assertion. But that will be the only place you will use it. Consider the alternative for such situations: do not declare a new variable for such a case, and instead, pass the desired value of the variable inline, directly into the construct that needs to use it. That will change the above code to the following one (the ‘someVariable’ variable will be used in several places in my test):

assertEquals(someVariable, “This is the expected String”); 

In the first code snippet that I wrote I clearly had an excess of one line of code that I did not really need. Such a declaration would have been useful only if the ‘expectedString’ variable would have been used in several places across my test or my code project. And think about it at a larger scale. In my example, I have 1 line of code that was not needed, but in case I had 1000 tests, each with one such extra line of code, I would have gathered 1000 lines of unneeded code easily.

And that unneeded line of code did not help much with the readability of the test either. If you have a test class with 20 tests, each of them declaring such a variable, maybe at class level, you would have to read through 20 lines of declarations before getting to the part you are interested in: the tests. Since coding practices suggest that the classes should have a decent size in number of lines of code, make sure you don’t clog them with such unneeded declarations. Use inline values wherever possible.