280 likes | 403 Views
Test-Driven Development. An introduction for C# developers. Who I am. Mathias Brandewinder Background in business and quantitative analysis methods Develop in C#/.NET for the past 5 years Started my own business since over a year www.clear-lines.com/blog. My goal for today.
E N D
Test-Driven Development An introduction for C# developers
Who I am • Mathias Brandewinder • Background in business and quantitative analysis methods • Develop in C#/.NET for the past 5 years • Started my own business since over a year • www.clear-lines.com/blog
My goal for today I would like you to be able to start as you leave the room
Approach • Interactive: write code live • Focus on C# • Focus primarily on NUnit • Covering also Visual Studio 2008 tools • Assuming little or no background in TDD/unit testing
The plan • What is TDD? • TDD in action: the basics • Using Nunit • Using VS2008 • Less basic TDD • Mocks • Beyond TDD • Questions
Test-Driven Development • Is a development methodology • Not a testing methodology • Aims for “clean code that works, now” • Write the test first, then the code which satisfies the test
Source • Test-Driven Development By Example, Kent Beck (Addison Wesley)
The rules Write new code only if an automated test has failed Eliminate duplication
Red/Green/Refactor Red: write a little test that doesn’t work, and perhaps doesn’t even compile at first Green: make the test work quickly, committing whatever sins necessary in the process Refactor: eliminate all of the duplication created in merely getting the test to work
Benefits: the obvious Simple and predictable Small steps Fully tested code from the get-go Very reassuring
Your mission, if you accept it Add a functionality to an existing application, to compute the distance between cities
A quick math reminder We will assume that “the world is flat” Distance between 2 points:
What have we seen so far? • [TestFixture], [Test], Assert • One test at a time • Write “as if” you had the feature done • Write tests as “sentences” • 3 patterns • Fake it ‘til you make it • Obvious implementation • Triangulate
What have we seen so far? Separate projects Debugging a test
Some classic useful test techniques TestRow Testing for exceptions Setup & Teardown
Mocks • “Subject under test” vs. Collaborators • Mocks to simplify your life • “Classicists”: by default, use the real thing • Mocks, the dark side of design patterns • “Mockists”: use Mocks in interactions
What have we seen so far? When testing the interaction of a class with another class, Mocks are a convenient way to “fake” the collaborator Focus on behavior and not state
Mocks and patterns MyClass Strategy: IStrategy IStrategy StrategyB StrategyA
A few questions What are the benefits of TDD? Does TDD slow you down? How much testing is enough? Does TDD mean no upfront design? What are good tests? Are TDD people terrorists?
To contact me… mathias.brandewinder@clear-lines.com