280 likes | 428 Vues
This interactive session provides a comprehensive introduction to Test-Driven Development (TDD) for C# developers. Over the course of this presentation, you'll learn the fundamentals of TDD, focusing on tools like NUnit and Visual Studio 2008. The goal is to empower you to start applying TDD practices immediately. We'll cover the key principles of TDD, including the Red/Green/Refactor cycle, and provide hands-on experience writing tests and code live. Suitable for those with little to no background in unit testing, this workshop will give you the necessary skills to produce clean, working code.
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