Learn The Unit Test Naming Convention

Are you running your unit test and obtaining a failure? How many times do we have to dig through the bus code and understand what it is complaining about? It matters because every time we read the test code will lose our precious time.

The feedback cycle lengthens, and we are breaking our stride. Instead, we should try to code using fast feedback. When we run naming conventions for JUnit and obtain a failure, we should understand what we have broken.

And we mainly want to do this without reading the test code. The test name alone could provide us with the information required.

Elements of Good Unit Test Naming Conventions

Let us put more information into the test name, and when a test fails, we should know three things:

Applying this naming to XCTest

With minor changes, we can follow this Convention on the Naming of Units: Annotate methods of research are also not included in the Apple XCTest system. We must begin with a prefix for checking. It might be strange to pair a camel box with underscores—a kind of ‘snake camel box.

In the production code, yes, so a feature name can express a concept. If it’s quick, it must be a camel case.” In the production code. But we try to express three things for a test name. We sometimes try to evaluate the same process for different inputs. We should think the emphasis is a clear separator, which divides the name into its separate parts.

Should the name of the test include the name of the method?

How explicit should all this be? Should “operation” in particular be a name for a method? Occasionally. However, we have to take care of that noise is created. In other words, the test names should be targeted, which describe conduct, not execution. Take into account the TDD Kata Bowling Game. The training aims to play a bowling game. Rather than a name such as:

• Test score with Twenty Zeros Rolled should be zero
• Calling it is easier
• test gutter game

The simpler name presupposes more bowling skills. We can use a simpler name, which implies the three parts when the coders share that understanding:

1. We already know how to test a bowling game.
2. A “gutter game” means each roll has gone in the gutter. The ball didn’t knock down a single pin.
3. The scenario score is zero.

Bowling rules are commonly understood—but not all. They are even not widely known for most domains. In case of doubt, explaining the operation, the information, and the result explicitly. Can we describe the “working unit” without using the name of the method? Yes, it can work for small types, like two non-private methods. It could be our guy if we’re uncomfortable taking this step. Smaller types should follow the Single Responsibility Principle.

Then when are we supposed to use method names? If you add useful information with the name of the method. We, as iOS programmers, are mainly working with the systems of Apple. A framework means that Apple could be called using methods. iOS developers are aggressively pushing each method, and many are there. It could be meaningful to use the method’s name – or some summary thereof – in the test for such code.

Pick a naming convention for JUnit that works for you

No matter what type of naming? We prefer, we should strive to express all three pieces. Choosing a mix that fits the team between terse and verbose. We can also adjust our mindset and rename our studies. Seek clarity and enhance titles by seeking new ways of doing so.

Most Popular Unit Test Naming Conventions

The following seven common unit tests naming conventions which the majority of developers use and compile from the pages above:

1. MethodName_StateUnderTest_ExpectedBehavior

There are arguments that if the name of the process changes as part of code rework, names like that could either change or it is impossible to interpret later. Such instances are as follows:

1. isAdult AgeLessThan18 False.
2. Withdraw money Invalid Account Exception Thrown.
3. Admit student Missing Mandatory Fields FailToAdmit.

2. MethodName ExpectedBehavior StateUnderTest

Somewhat tweaked from above, this naming method is also proposed by a developers section. This technology also has the drawback of being difficult to understand later as process names are modified. Then, in the first case, tests will read as if called using this technique:

1. isAdult False AgeLessThan18
2. Withdraw money ThrowsException IfAccountIsInvalid
3. Admit student FailToAdmit IfMandatoryFieldsAreMissing

3. Test [Feature being tested]

This makes it easy to read the test as the test feature is written part of the test name. But some arguments detect that the prefix is redundant. Nevertheless, many sections of developers love to use this technique. following is how the above tests would read like is named using this technique:

1. testIsNotAnAdultIfAgeLessThan18
2. testFailToWithdrawMoneyIfAccountIsInvalid
3. testStudentIsNotAdmittedIfMandatoryFieldsAreMissing

4. Feature to be tested

Many people have suggested that it is better for writing the features to be tested as it measures and notations for identifying test methods. It is also suggested that it makes unit tests and alternate from the documentation and avoids code smells. Following is how tests would read like it named using this technique in the first example:

1. IsNotAnAdultIfAgeLessThan18
2. FailToWithdrawMoneyIfAccountIsInvalid
3. StudentIsNotAdmittedIfMandatoryFieldsAreMissing

5. Should_ExpectedBehavior_When_StateUnderTest

Many people also use this technique as it allows easy reading of tests. Here is how the tests in the first example would read that this technique is named:

1. Should ThrowException When AgeLessThan18
2. Should FailToWithdrawMoney ForInvalidAccount
3. Should FailToAdmit IfMandatoryFieldsAreMissing

6. Where_StateUnderTest_Expect_ExpectedBehavior

This is how in the first instance tests would read if this technique had been named:

1. When AgeLessThan18 Expect isAdultAsFalse
2. When InvalidAccount Expect WithdrawMoneyToFail
3. When MandatoryFieldsAreMissing Expect StudentAdmissionToFail

7. Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior

This strategy is focused on the designation of the Convention as a part of conduct-oriented growth (BDD). The aim is to divide the experiments into three parts to define the prerequisites, the test condition, and the predicted behavior above. It is how the first case studies would read as if they were called using this technique:

1. Given UserIsAuthenticated When
2. InvalidAccountNumberIsUsedToWithdrawMoney Then TransactionsWillFail

Also Read: How to perform Unit testing with xUnit?