Philly.Net TDD Workshop
Last night, I attended Brian Donahue’s excellent Getting Started With Test Driven Development workshop in Ft. Washington PA as part of Philly.Net’s workshop series. Brian originally gave a workshop entitled Building Maintainable, Testable WebForms Applications with the Model-View Presenter Pattern. This was back in July. I think the consensus was that for the July workshop, the presentation was rushed and difficult to follow, so Brian went back and reworked the whole concept and produced a stunning result. He was really able to focus on some of the reasoning behind TDD. The pace was much slower than before but still brisk enough not to get bored. Brian had some great advice on getting started and coping with some of the trappings of TDD. While following along writing code, it became obvious that you need a tool like Resharper in order to boost the efficiency of the manual coding effort. Resharper is almost like magic.Here’s some notes I took during the workshop. These are my thoughts and not Brian’s words - Brian might or might not agree at all:
Brian recommended the class Nothin’ but .NET Developer Boot Camp http://jpboodhoo.com/training.oo Coming to Philly Nov 17th-21st. $3,000.00
TDD summary: Red. Green. Refactor.
CodeCamp server is on Google code and is an MVC project that’s test driven. Study that for some direction.
Specs - Specifying what you expect your objects to do.
Using NUnit attributes:
[TestFixture] - Defines the context. There should be a different context for each problem you’re trying to solve.
[SetUp] - runs once before each test. Sets up the context for the tests.
And so, the class name + the method name should make a nice sentence.
When_running_the_import <-Class.Method-> Should_parse_file_at_specified_path
The granularity of this is determined by the complexity of the [SetUp]. If the SetUp is getting complex, it’s time to break up the context (TestFixture).
Example:
1. logging in with valid credentials. 2. logging in with invalid credentials. These are different contexts.
An aside (When using SVN, the idea is to do an Update first and then do a commit.)
Dependency Injection involves passing something that is needed to a class as a constructor argument.
As the tests are being written, the code you want is materializing almost as a side effect. As you go, you are being forced to define the public view of your classes and interfaces. You use mocks to pass the tests.
Unit tests are intended to test just small units of stuff, typically using Mocks to avoid needing to set up complicated environments.
Integration tests would test the whole stack, i.e. actually importing a file, parseing extracting stuff, etc.
Assert.AreSame() means the two references point to the same thing (object).
