This could be interesting in more ways that one.

And he starts with the “I don’t feel embarrassed about perfect feedback scores” statement.

Sub title on the presentation is From Unit Testing to Behaviour Driven Design.

Common statements to challenge:

• Unit tests are documentation
• TDD is design

You must look at tests as documentation for anyone but you.

Scott’s going to show the evolution of unit tests (using nUnit) over the years.

Story represents functionality, not specification.  It’s for naming/identifying and then moving through planning.  Also known as placeholders for conversation.

Preferred customer discount example is a good one.

Here’s how I would have written it 5 years ago….and there’s generics in it?  I know….picky me.

Buddy next to me has the loudest laptop ever.  D’Arcy had the slowest last year and now I’ve seen the loudest.  What did I do to be punished with people who have shitty laptops?

The 5 years ago example shows that writing code all in one method has ramifications on the size and complexity of your tests.  You end up creating a lot of line noise (lines of code that have to be there, but don’t directly relate to the task at hand).

Tool that pulls out the test names from the testing assembly and creates a document.

Test naming is important, both for clarity and documentation.  Ripping the test names out should allow you to convey the purpose of the testing to a non technical human.  Naming tests based on their real purpose.  If you’re testing a 10% discount for preferred customers, naming should focus on the discount, not the customer or the preferred status.

BDD asserts that focusing on the behaviour will allow the domain language to be created naturally and in a sensible state.

Two types of people who should be tagged with creating a domain specific language are documenters and testers.

You can find inconsistencies and duplications or incorrect domain language by handing the testing names off to non-coders.  These can be software design issues (aka. spec issues).

I’m not seeing a lot of information on BDD yet.

The coding and refactoring in this presentation is painful.  Maybe I’m to used to JP.

Hot Agilista update!  They’re in this presentation, but they look like it was a rough night.  Maybe they saw Woodsy dance last night.  I know that made me feel worse than normal this morning.

Wow.  15 minutes to show parameter based injection of a data access object on a method.  People are starting to fade…..

The argument that decoupling code will provide better documentation thorough the tests.

Sometimes you will have tests with large amounts of setup, but you should be doing everything in your design power to avoid this situation.

Simple tests tend to force you to write simple and loosely coupled code.

Finally!  JP has taken over the keyboard and design of the code.

JP has finished and things look way different, but the coding pace is painful.

Scott shows NUnit.Spec that shows his extension method work.  The syntax is quite clear and helps to flush out the readability through natural language structuring in your code.

order.GetTotal().ShouldEqual(150);