Underscoring A Point

This last week I took a great class on TDD and BDD given by Scott Bellware. During  the session   he showed us a cool tool called AutoHotKey. AutoHotKey is a tool that allows you to control your keyboard behaviors. For instance you can use AutoHotKey to substitute the underscore character for a space when typing in a test name

I had a discussion with my co-worker Greg Lawrence about using underscores vs.  CamelCase for our test naming conventions. I have always liked underscores in test names. Test names are like sentences and should be read as such. To drive this point home (and to demonstrate it for an underscore bigot :) I present the following:

Original Test

We hold these truths to be self-evident, that all men are created equal,
that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.





BDD CamelCase Notation


  • ShouldIncludeLife
  • ShouldIncludeLiberty
  • ShouldIncludeHappiness

BDD Notation (Underscored)


  • Should_Include_Life
  • Should_Include_Liberty
  • Should_Include_Happiness

As is self evident (pun intended) the underscored version is much easier to understand and read.  When you generate documentation from your BDD specs which one make more sense? Which will is easier to use by your customers? Which ones can you substitute underscores for spaces when printing documentation? Its pretty obvious which one to choose.

Just a small thought on this march morning.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

10 Responses to Underscoring A Point

  1. codemnky says:

    I am stuck in a unique situation. I work for a small company, where they purposely keep information hidden about the overall architecture. Our codebase is in the midrange space and all procedural. We are re-writing our whole package in dotnet. my project manager makes 3 times the money I do, yet I am the only developer who has any knowledge about dotnet and all the SOLID principles and all the alt.net principes such as Persistence Ignorance and separation of concerns beyond the layered architecture. Should I code in a way that is maintable by any coder out there. Or should I make it so tightly coupled and cryptic, where my job is secured?

  2. Afif,

    It appears that the mechanics have been beaten to death, but that there is still very little understanding.

    Why are we assuming that blogging will solve this? Context specification is powerful because its effects are subtle but pervasive. In order to capitalize on the pervasiveness, you have to develop a visceral feel for the subtlety.

    No one can just hand over subtle knowledge in any form or artifact – blog or other wise. So rather than asking the bloggers to serve you, why are you not serving the bloggers? You can do so by practicing.

    Practice will give you the understanding that you’re looking for. Subtle knowledge is only available through practice.

    If you spend all of your hours believing that you can learn anything to the extent necessary to do no harm by merely being served with artifacts, then you won’t learn anything of great value. You’ll be stuck with middling value and a mere materialistic sense of knowledge and learning.

    Some fields of learning are simply not compatible with this kind of passive learning. Context specification is one of them. Anyone can go through the motions, but merely mimicking context specification’s mechanics and outward vestiges isn’t itself context specification.

  3. Afif says:

    I agree with Liam. Please note that I have used JP’s concern and observation style tests in my last project and I was more satisfied at the maintenance quotient of my test suite. But it ended there. I gather BDD is not just about writing context specs., it’s a style of development. And I know nothing about it., can’t ever remember any one ever blogging about it in a manner that the design part of it becomes evident.
    So yes to sell it just on the premise of underscores it like saying the best part of TDD is you get 100% code coverage.
    Guys., for everyone one who understands BDD please start blogging about how to understand the designing part of it., the testing with context specifications and underscores has been beaten to death.

  4. Jason
    Thanks for the reference to look at. I’ll defintely check it out.

  5. Liam
    I am not an expert nor do I claim to be an expert on BDD. But I can see that the type of structure that is used in BDD adds creater clarity to the design of applications and the organization of tests. If we can use the notation to produce documentation artifacts to discuss design decisions with the customer how is that a negative?

  6. Hi Matt
    You know I gave the camel case deal some thought as well for methods and such. I came to my own conclusion that I would continue camel casing methods as they serve a different purpose IMO. Could be a contradictio I supposed but I did say that this standard made more sense for testing and BDD.

  7. Liam and Jason,

    It seems to me that you’re presuming a lot of understanding here that is clear to me is not in your possession.

    If you’re merely writing unit tests, and merely adding underscores to test names in order to transform them to plain language documentation, are you doing the method and the practice that I teach?

    I agree with your points about the irrelevance of unit tests to customers, but context specification is simply not in the same paradigm as unit testing and therefore the notion of unit tests is alien and not applicable.

    So where do you go from here? Will you get actual knowledge and experience about the method, or merely continue to wax presumptively?

  8. Jason says:

    if you like underscores for testing check out bdddoc by jean-paul boodhoo. this will generate that reads like sentences without the underscores.

    BDD ties in closely with Agile development and one of the aspects is to remove impedance to productivity (producing code). Documentation can be seen as an impedance since it doesn’t result in functionality. However, customers want documentation on some level. so a report generated by tests can meet that requirement.

    I do agree that customers would not want to see documentation on unit tests. however you could use this naming convention along with bdddoc to report on key integration tests. Primarily I am thinking of business workflow tests.

    public class when_a_client_places_an_order{
    public void an_email_should_be_sent_to_the_client() {… }

  9. Liam says:

    That’s actually Pascal Case, not Camel Case.

    And I think that your example is flawed. Why is the BDD sample given reasonable names yet the others are just the entire text. I don’t really think this is in good faith.

    I *guess* the BDD styles would generate a report better than something like :

    Men are created equal
    Men have unalienable rights
    Men’s rights include life
    Men’s rights include liberty
    Men’s rights include happiness

    On the other hand, no they won’t.

    I am SO fed up with BDD people spewing the documentation rationale. It doesn’t fly, and even if it did, it takes a special kind of moron to think customers care about unit test results outside of pass/fail and maybe coverage. Automated UI test reports, sure, but who cares about this?

    How about some rationale where BDD improves code design. That’s the ticket, right there. That’s the golden goose, my friend, not this lame documentation excuse. Once you guys convincingly correlate better design with BDD it’ll be all over for the traditionalists.

  10. Matt McClellan says:

    If you’re going with underscores, why continue with CamelCase as well?

Leave a Reply