Today I had an opportunity to go to the TDD Coding Dojo hosting by Chad Myers and Ray Houston and I had a blast.  Some of the attendees have been doing TDD for a while (some have even migrated to instituting BDD into their development process) and some of them were trying to see what TDD was all about.  I think those people left with a better understanding of what TDD truly is and can be in their own development environments.

Getting to the purpose of this post:  I was noticing that there was a lot of hang up on test method names during the dojo.  I know that you almost can't even write a test without knowing what you want to assert on your domain/service/etc..  I personally sometimes start with the following:

   1: [Test]

   2: public void X()

   3: {

   4:  

   5: }

After making the test fail, I rename it to this (say this test was in the context of a US citizen having a passport):

   1: [Test]

   2: public void should_be_able_to_travel_abroad()

   3: {

   4:  

   5: }

I usually write my test and my assertions, just to "do the simplest thing to get it to work".  I apply that philosophy to TDD too.  I want to do the simplest thing to get through Red-Green-Refactor.  I've paired with developers -- and have been guilty of this in the past too -- that spend more time on thinking of the test method name or the class context name instead of writing code.  It's a test in the first place, right?  I'm not "Joshing" the method-naming-first developers.  I can appreciate the fact that this is a personal choice.  I also expect to be asked, "how can you write your test if you don't know what you are going to test?"  My answer is, "I let the code tell me and I just want fingertips on the keyboard".  Hell, that is what F2 (Rename in ReSharper) is for.  I rename my method and context (TestFixture class name) accordingly after I see Red.  If upon passing and refactoring the test, the name needs to change again, hit F2.

What are your thoughts?