Search The Blog
Latest Posts
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course



This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

« Zen of python revisited with code samples | Main | What does the 'unit' in 'unit test' mean? »

Test Naming Conventions With Unit of Work

When I name my tests I use the name of the “unit of work” as the first part. If the unit of work is bigger than a method, I usually name the test with the name of the initial public method that starts the unit of work. 

Test names are affected by the type of end result we are expecting. So a test might look like this for a return value result:


or like this for a state change result:


or like this for 3rd party end results (when we use mock objects):



the first part is the unit of work. the second part is the scenario. the third part is the expected end result or behavior of the system.

PrintView Printer Friendly Version

Reader Comments (1)

I find this kind of naming style too terse for tests. Kevlin Henney suggests that the test name is a proposition, which when viewed as a collection can be seen as an executable specification of sorts. By taking a leaf out of the BDD naming convention book (given/when/then) you can make things much more readable and easier to write in the first place, e.g.




I personally favour the <Feature>_<Should>_<When> order as it's the scenario that often varies subtly, rather than the outcome. Also, liberal use of underscores should not be underestimated to aid readability of lengthy test names, e.g.


May 16, 2012 | Unregistered CommenterChris Oldwod
Comments for this entry have been disabled. Additional comments may not be added to this entry at this time.
Web Analytics