Comments on the urban canuk, eh: TDD Tips: Test Naming Conventions & Guidelines

Thanks for pointing that out cliff. I wish my blo...

2009-07-23T01:48:50.561-04:00

Thanks for pointing that out cliff. I wish my blog writer had intellisense.

you need to update your list of points above. You...

2009-07-22T14:54:20.202-04:00

you need to update your list of points above. You should refer to "TestFixtureSetup/TestFixtureTearDown" instead of "SetupFixture/TearDownFixture"

That's an interesting question Afzi: TDD does impa...

2008-06-15T14:38:00.000-04:00

That's an interesting question Afzi: TDD does impact the way we write code, but expressing it as do-n-don't would fall under a different category than those listed here. I'll chew on that, maybe post something in the future.

Generally speaking, I think TDD discourages "blackbox" code, where code is organized to do anything and everything without sharing any details of how it will perform those tasks. TDD in contrast, the focus is on writing testable code, so you end up with open-ended, cohesive sets of specialized objects. Each set of objects can be tested independently of each other and can also be substituted with test versions to assist in testing larger related components. TDD and Inversion of Control / Dependency Injection go very well together.

How does TDD influence the way we write objects? C...

2008-06-06T15:36:00.000-04:00

How does TDD influence the way we write objects? Could you give some insight on this as well please?

>> replace that AVOID with a recommendation to pic...

2008-06-06T08:31:00.000-04:00

>> replace that AVOID with a recommendation to pick a consistent style that is easily understood and flexible to change.

Now that is something I can get on board with. :)

Steve, I probably could have elaborated better on ...

2008-06-05T09:55:00.000-04:00

Steve, I probably could have elaborated better on the underscore recommendation. I'll admit the motivator of not having to hold down the shift key is poor.

My motivation is that your tests are different than your API for your production code in that Test names have a tendency to change over their lifetime. As a personal preference, I find methods with underscores clunky and I rely on tools to create them for me (creating event handlers, etc) rather than type them by hand.

Honestly, any style will do (compared to not writing tests) and if you have tools that work well with that style, then you might enforce that style as a recommendation within your organization.

I should probably amend the list, and replace that AVOID with a recommendation to pick a consistent style that is easily understood and flexible to change.

w/r/t: "AVOID: Using underscores as word-separator...

2008-06-05T09:30:00.000-04:00

w/r/t: "AVOID: Using underscores as word-separators"

Saving time by not having to hit the Shift key is so not a reasonable argument against using a naming-style that increases solubility as much names_with_underscores_does. Especially if you use something like AutoHotKey (http://www.jpboodhoo.com/blog/BDDAutoHotKeyScriptUpdateTake2.aspx) to replace a space with an underscore for you! :)

I'm not saying that PascalCasing is bad or that it should be avoided, I'm only saying that using underscores is equally viable... and IMO, a more readable style. I find this especially true when used with some of the newer BDD frameworks that can generate HTML reports from your Test/Spec names.

This is actually really good. It's a great startin...

2008-06-05T08:58:00.000-04:00

This is actually really good. It's a great starting point when establishing the unit test standards and your organization.