Nov 11, 2011

Underscores in Test Names are a Pain to Type, Right? Not Anymore!

It might be a large assumption given some of the customers I deal with, but I’m going to assume you write unit tests.  I’m also going to assume that when you write tests your test names have underscores separating all the words and making your test names human readable. Something like This_is_a_really_long_test_name_but_thats_ok_because_its_easy_to_read_when_I_use_underscores.

The only (minor) problem I have with this approach is that underscore isn’t the easiest key to type.  I’d rather just hit the space bar and have Visual Studio change that space to an underscore for me – after all, that’s exactly what computers are good for :-)

Here’s the good news, there’s a great little ReSharper macro that has been developed that does just that – it’s available from and all you need to do is create an R# live template that wires the macro up to your test name field in a live template.  For example:


Now when you use the live template to create a test you can simply type the test name with spaces and they’ll be converted into underscores for you automagically.  Fanstastic!

Kudos to Joar Oyen for his great work, and feel free to check out his blog post for how this works under the hood.


  1. Hmm interesting. We tend to stay away from underscores. The main reason is if an editor or something ever underlines it then you can have trouble telling where the underscores are and where just normal spaces are.

    You might also try (depending on what you prefer of course) using CamelCase (

    An example is...


    It actually still is very readable. :)

    It also depends on your coding standards and language. It is great to sit down and write a coding standard so that everyone is on the same page to start with. That way when some code comes up for review and it doesn't fit the standard you can ask your engineer to refactor it to suit. The end result is code that is consistent and doesn't make people jump through mental hoops every 2 seconds trying to understand the code.

    Our practice is to always imagine we are writing code that a completely new employee (armed with our coding standards) might need to sit down and work on it tomorrow. Or another exercise is to imagine that you may not look at or think about the project for 2 or 3 years. That is a good length of time and you would be surprised what you can forget in that time.

    What ever you do if you don't code with consistent, readable and well documented code you may never be able to extract yourself from the process and will have to keep working on code that only you can read and understand.

  2. Camel and pascal casing only really works up to about 30 characters or so. After that your brain has to work too hard to parse the text, which is why underscores for test names are generally a better approach. Also, when you look at a long list of tests after a test run then it's very easy to read the test names.

  3. I use an AHK script from here that I probably originally found on Dave Tchepak's blog, so I just hit CTRL-Shift-U to toggle naming mode, which_I_can_do_ANYWHERE but it can catch me out sometimes ;-)