Naming is one of those underrated things when it comes to test automation code. Many times, when you look at variable or even test method names, they are not very suggestive and you have a hard time figuring out what their purpose is. In this post you will find a few reasons why it is important to name things properly, and some tips about how to find the good names your code deserves.
Naming is mostly useful when you are trying to find something, but also when you are reading a test. Proper naming helps understand what the test does and what it is intended for.
When it comes to naming things, there is always a limit of how long a name can be. If we are talking of a class name, this is limited by how many characters a file can have on the operating system where you run the tests. Therefore, when naming things, make sure you follow this simple rule: create a name as meaningful and short as possible. Sometimes it’s difficult to condense all the meaningful things into just a few characters, but abbreviations are always an option, as long as everybody understands what they mean.
Oh, and don’t forget to use the guidelines for naming Java entities: camel case; package names start in lowercase; class names start in Uppercase; method names start in lowercase; variable names start in lowercase.
Project names: the first item you need to make sure you assigned a relevant name to is the project where you will store all your test code. This will correspond to the entry you will have in your version control tool (e.g. Git). What you can include in the name of the project, depending of course on your project’s specifics:
– the purpose of the project, or the name of the product or area of the product you are testing in this project
– it might be useful to mention if it is a back-end or front-end project. If it’s a mix of all that, this information does not appear useful. It is though when for the same product you separate your backend and front-end tests on a code project level.
– if you have a project dedicated to just one environment, for example production, you can add this name in the project’s name. Or if you have a category of environments to which this test project corresponds, like “everything but production” or “all dev environments” you might want to add this information too.
– the name of the team who will work on this project, if you know for sure that this will be the team who will own the project for all times
Package names: you will surely use some packages to group tests together. The package name should suggest the reason why all the tests in the package are found there. For example, they might test the same feature, or might be dedicated to doing sanity on the product, or maybe you can link the package name to an epic id or summary from a Jira item (or whatever else tool you are using).
Class names: if we are talking of classes that hold the tests, the name of the class should reflect the purpose of all of the tests from this class. If we are referring to the name of a class that is not a test class, but instead groups together code used by tests, like utility or helper code, the class name should reflect its purpose too. For such a case, people normally use one of the following words in the class name to specify the purpose: helper or util. But also add some relevant words to suggest what the class is helping with, like: BrowserHelper, DBQueryUtil. Make the names as specific as possible, not something as general as: TestHelper. That can mean too many things and not the same thing will be understood by everyone.
Methods: of course, the test method name should clearly reflect what we are testing in this method. Again, a comprehensive name is desired, but not a 500 character long one. It is usually tricky to find a suitable name for methods, since they might have a lot of steps that will be run. Thing about the class name: it already specifies part of what the test will be doing, as it will identify the area of the application it tests. The method name will just give more details about what scenario is tested in that area. There is no need to add the same words in the method name as what was added in the class name. For example, if the class name is ‘ShoppingCartTest’, the method name should not be ‘shoppingCartHappyFlow’. It can just be ‘happyFlow’ since the class name already implies that we are testing something regarding the shopping cart. Another ‘type’ of method so to say is a helper method. Having it named properly will help with the readability of the test method. Let’s say that in the ‘happyFlow’ test method from the ‘ShoppingCartTest’ class you are calling a helper method to add some products to the cart. By naming this method “addMoreProducts” you can easily read the test as having a step where the number of items in the shopping cart will increase (instead of calling this method “cartHelper” which does not suggest what it helps with).
Variables and constants: these shouldn’t be neglected either, since they are in great numbers across tests and might make understanding the code very tricky, if they have generic names. For example, let’s say you read a String and store it to a variable, after which you need to split this String into two different variables, parse each of them into a different format and into a new variable, and then convert them somehow, by storing them to another variable. These are many steps to be done and many variables are needed to store the result of processing the initial String. So, as to keep track and understand what String you are now looking at, the naming is essential. Obviously “variable1” and “variable2” are not the names you are looking for.
I have seen many developers spend quite a good few minutes when creating that name that properly reflects the purpose of what is named, so us as automation testers should not be shy in doing the same.