Unit test naming best practices

Question

What are the best practices for naming unit test classes and test methods   This was discussed on SO before  at What are some popular naming conventions for Unit Tests   I don t know if this is a very good approach  but currently in my testing projects  I have one-to-one mappings between each production class and a test class  e g  Product and ProductTest   In my test classes I then have methods with the names of the methods I am testing  an underscore  and then the situation and what I expect to happen  e g  Save ShouldThrowExceptionWithNullName

User · Answer

Class Names  For test fixture names  I find that  Test  is quite common in the ubiquitous language of many domains   For example  in an engineering domain  StressTest  and in a cosmetics domain  SkinTest   Sorry to disagree with Kent  but using  Test  in my test fixtures  StressTestTest   is confusing     Unit  is also used a lot in domains  E g  MeasurementUnit    Is a class called MeasurementUnitTest a test of  Measurement  or  MeasurementUnit    Therefore I like to use the  Qa  prefix for all my test classes  E g  QaSkinTest and QaMeasurementUnit  It is never confused with domain objects  and using a prefix rather than a suffix means that all the test fixtures live together visually  useful if you have fakes or other support classes in your test project   Namespaces  I work in C  and I keep my test classes in the same namespace as the class they are testing  It is more convenient than having separate test namespaces  Of course  the test classes are in a different project   Test method names   I like to name my methods WhenXXX ExpectYYY  It makes the precondition clear  and helps with automated documentation  a la TestDox   This is similar to the advice on the Google testing blog  but with more separation of preconditions and expectations  For example   WhenDivisorIsNonZero ExpectDivisionResult WhenDivisorIsZero ExpectError WhenInventoryIsBelowOrderQty ExpectBackOrder WhenInventoryIsAboveOrderQty ExpectReducedInventory

User · Answer

Kent Beck suggests    One test fixture per  unit   class of your program   Test fixtures are classes themselves  The test fixture name should be    name of your  unit  Tests  Test cases  the test fixture methods  have names like   test feature being tested     For example  having the following class   class Person       int calculateAge                   other methods and properties     A test fixture would be   class PersonTests        testAgeCalculationWithNoBirthDate                   or      testCalculateAge

User · Answer

I like this naming style   OrdersShouldBeCreated    OrdersWithNoProductsShouldFail      and so on  It makes really clear to a non-tester what the problem is

User · Answer

the name of the the test case for class Foo should be FooTestCase or something like it  FooIntegrationTestCase or FooAcceptanceTestCase  - since it is a test case  see http   xunitpatterns com  for some standard naming conventions like test  test case  test fixture  test method  etc

User · Answer

I like to follow the  quot Should quot  naming standard for tests while naming the test fixture after the unit under test  i e  the class   To illustrate  using C  and NUnit    TestFixture  public class BankAccountTests      Test    public void Should Increase Balance When Deposit Is Made            var bankAccount   new BankAccount         bankAccount Deposit 100        Assert That bankAccount Balance  Is EqualTo 100           Why  quot Should quot   I find that it forces the test writers to name the test with a sentence along the lines of  quot Should  be in some state   after before when   action takes place  quot  Yes  writing  quot Should quot  everywhere does get a bit repetitive  but as I said it forces writers to think in the correct way  so can be good for novices   Plus it generally results in a readable English test name  Update  I ve noticed that Jimmy Bogard is also a fan of  should  and even has a unit test library called Should  Update  4 years later     For those interested  my approach to naming tests has evolved over the years  One of the issues with the Should pattern I describe above as its not easy to know at a glance which method is under test  For OOP I think it makes more sense to start the test name with the method under test  For a well designed class this should result in readable test method names  I now use a format similar to  lt method gt  Should lt expected gt  When lt condition gt   Obviously depending on the context you may want to substitute the Should When verbs for something more appropriate  Example  Deposit ShouldIncreaseBalance WhenGivenPositiveValue

User · Answer

I use Given-When-Then concept  Take a look at this short article http   cakebaker 42dh com 2009 05 28 given-when-then   Article describes this concept in terms of BDD  but you can use it in TDD as well without any changes

User · Answer

I like Roy Osherove s naming strategy  It s the following   UnitOfWork StateUnderTest ExpectedBehavior  It has every information needed on the method name and in a structured manner  The unit of work can be as small as a single method  a class  or as large as multiple classes  It should represent all the things that are to be tested in this test case and are under control  For assemblies  I use the typical  Tests ending  which I think is quite widespread and the same for classes  ending with Tests    NameOfTheClassUnderTestTests  Previously  I used Fixture as suffix instead of Tests  but I think the latter is more common  then I changed the naming strategy

User · Answer

See  http   googletesting blogspot com 2007 02 tott-naming-unit-tests-responsibly html  For test method names  I personally find using verbose and self-documented names very useful  alongside Javadoc comments that further explain what the test is doing

User · Answer

In VS   NUnit I usually create folders in my project to group functional tests together  Then I create unit test fixture classes and name them after the type of functionality I m testing  The  Test  methods are named along the lines of Can add user to domain   - MyUnitTestProject        FTPServerTests  lt - Folder      UserManagerTests  lt - Test Fixture Class      - Can add user to domain   lt - Test methods      - Can delete user from domain      - Can reset password

User · Answer

I recently came up with the following convention for naming my tests  their classes and containing projects in order to maximize their descriptivenes   Lets say I am testing the Settings class in a project in the MyApp Serialization namespace   First I will create a test project with the MyApp Serialization Tests namespace    Within this project and of course the namespace I will create a class called IfSettings  saved as IfSettings cs    Lets say I am testing the SaveStrings   method  -  I will name the test CanSaveStrings     When I run this test it will show the following heading   MyApp Serialization Tests IfSettings CanSaveStrings  I think this tells me very well  what it is testing   Of course it is usefull that in English the noun  Tests  is the same as the verb  tests    There is no limit to your creativity in naming the tests  so that we get full sentence headings for them    Usually the Test names will have to start with a verb   Examples include     Detects  e g  DetectsInvalidUserInput  Throws  e g  ThrowsOnNotFound  Will  e g  WillCloseTheDatabaseAfterTheTransaction    etc   Another option is to use  that  instead of  if     The latter saves me keystrokes though and describes more exactly what I am doing  since I don t know  that the tested behavior is present  but am testing if it is    Edit   After using above naming convention for a little longer now  I have found  that the If prefix can be confusing  when working with interfaces  It just so happens  that the testing class IfSerializer cs looks very similar to the interface ISerializer cs in the  Open Files Tab    This can get very annoying when switching back and forth between the tests  the class being tested and its interface  As a result I would now choose That over If as a prefix   Additionally I now use - only for methods in my test classes as it is not considered best practice anywhere else - the     to separate words in my test method names as in    Test  public void detects invalid User Input     I find this to be easier to read    End Edit   I hope this spawns some more ideas  since I consider naming tests of great importance as it can save you a lot of time that would otherwise have been spent trying to understand what the tests are doing  e g  after resuming a project after an extended hiatus

User · Answer

I think one of the most important things is be consistent in your naming convention  and agree it with other members of your team    To many times I see loads of different conventions used in the same project

User · Answer

I should add that the keeping your tests in the same package but in a parallel directory to the source being tested eliminates the bloat of the code once your ready to deploy it without having to do a bunch of exclude patterns   I personally like the best practices described in  JUnit Pocket Guide      it s hard to beat a book written by the co-author of JUnit

[unit-testing] Unit test naming best practices

Examples related to unit-testing

Examples related to naming-conventions