How should we name the automated tests?

Question

I was reading articles about best practices of test automation and I found something interesting. An author of Top 15 UI Test Automation Best Practices You Should Follow, Yuri Bushnev, wrote:

This is an example of a bad test name:

@Test public void
flightSearchTest() {.....} 

It is bad because it doesn’t tell any details about the test scenario. This is an example of a well named test:

@Test public void
userShouldBeAbleToFindFlightsFromBostonToNewYork() {.....}   

This test name is much better because in the case of a failed test, you immediately understand which functionality failed and you don’t need to go inside the test and verify which it actually does. It’s just a matter of taste, but many engineers prefer to use the “_” separation approach instead of the CamelCase:

@Test public void
user_should_be_able_to_find_flights_from_Boston_to_New_York() {.....} 

But again, this is just a matter of taste.

I'm not experienced in test automation but it's the first time when I see that someone is using this kind of name convention. I'd like to ask for your opinion and your experience, best practices in this area

Answer 1

My personal opinion is it depends.

Why do we need to carefully name a method?

• We need to pass on information as concise as possible to other people and to ourselves in a few weeks.

Programming is very much like telling a story to others, it is not just about us, it is more about other people. So:

• Can you please first consult with your technical peers about establishing a naming convention?
• If there is already a naming convention in place, follow it.

I have personally encountered the following problems regarding naming:

• Company's official styling plug-in does not like certain names, especially long names. I understand a longer name is normally more descriptive, but it does not help if it triggers styling warnings all the time.
• Some applications may not recognize excessively long names, the program would not even build without errors.

In the end, you will notice you'll have to make compromises between information-richness and length and company styling policy and peer-pressure. What is acceptable in one company may be a taboo in an other.

Answer 2

The whole idea is, a failed test by the name itself should tell the specifics of what functionality is broken.Ex. reviseOrderToChangeColor

In my personal opinion, what specific convention you follow does not matter much if fulfills the end goal.

Answer 3

IMO, It is suggested to name the tests in meaningful way to let the peers know what the test case do, by reading the name itself We generally follow this structure however you can tailor it as per needs.

<ShortSummaryofWhataTestCasedo> and followed a comment having a traceability feature/Story that the test case is part of.

TC_<uniqueid>_<AppName>_<ModuleName>_<Story/featureName>

This would let other technical and non technical testers to understand what an automated test do and if require others find it easy to search through automation repositories and maintain it.