Mastering Test-Driven Development in C#
Two hands-on days turning TDD from a thing the team has read about into a thing the team does.
- Format
- 2-Day Intensive
- Duration
- 2 days
- Group size
- 12 to 25
- Level
- All levels
“Test-Driven Development changed the way I write code.”
Your team has heard someone say that. Probably with the evangelism that makes everyone else back away slowly.
The claims are real enough. Fewer bugs. Code that survives contact with next year. A suspicious calm around deployment.
So why isn’t everyone doing it?
Because TDD is simple to explain and hard to hold. Reading about the cycle takes an afternoon. Making it a reflex takes practice, with someone watching, on problems that push back.
That’s what these two days are. Not a lecture with exercises attached. Two days of pairing, mobbing and arguing about design, in C#, with the tools your team already uses.
Day two is the one that matters. Anyone can test-drive a kata. The question is what happens when there’s a database, a legacy module nobody owns, and a deadline.
What your team leaves with.
Outcomes · 5- The Red-Green-Refactor cycle practised often enough to stop feeling like ceremony
- Tests that drive design decisions rather than confirm them afterwards
- Ways to test-drive code that talks to databases, queues and third parties
- An approach to legacy code that does not start with a rewrite
- A read on where AI tools help the cycle and where they quietly break it
How the days run.
2 daysFoundation and core practices
Build the habit through repetition. Small problems, many cycles, in pairs and mobs.
- The Red-Green-Refactor cycle, practised until it is boring
- The 3 Rules of TDD and the 4 Rules of Simple Design
- Driving patterns, Fake It and Triangulate
- Refactoring technique, and improving the tests themselves
- Solitary and sociable tests, and when each one fits
- Mutation testing as a check on whether the tests mean anything
- Test lists, and decomposing a problem you cannot hold in your head
Real-world TDD and team adoption
Take it where it gets hard. Dependencies, legacy code, and the colleague who thinks this is a waste of time.
- External dependencies, test doubles and mocking strategy
- Outside-In TDD and the London School
- Legacy code, and approval testing as a way in
- The test pyramid and the architecture underneath it
- Adoption inside a team, and the anti-patterns that kill it
- AI tools in the loop, where they help and where they don't
Who it's for.
Hands-on- Teams who have built C# applications and written some unit tests
- Teams who tried TDD, found it slow, and put it down
- Anyone who wants better design, not just more tests
- Experience building C# .NET applications
- Basic familiarity with unit testing
- Their usual IDE, Visual Studio, Rider or VS Code
- Willingness to work in pairs and mobs for two days
Adapted to your team.
Before the dayWhat's above is the shape, not a script. We start with a 30-minute call about your codebase, your stack and what your team has already tried. The exercises get rebuilt around that, and anything that doesn't apply to you gets cut.
- The examples, moved into your domain
- The depth, tuned to the room
- The length, from 2 days to what your calendar allows
Questions we get.
FAQ · 5We tried TDD once and it slowed us down. Why would this be different?
Because reading about the cycle and having it as a reflex are two different things. Most teams put TDD down in the first week, before it has paid anything back. Two days of pairing and mobbing is what gets your team past that point, and it is the part a book cannot do.
Does the team need to know TDD already?
No. It runs at all levels and day one starts from the cycle itself. Teams who already write tests usually have more to unlearn than teams who do not, so experience is not the advantage it sounds like.
Our codebase is legacy. Does TDD still apply?
That is most of day two. Your team works on getting tests around code that was never built for them, using approval testing as the way in. Nothing here starts with a rewrite.
Will AI coding tools make this obsolete?
The opposite, so far. Generated tests are easy to get and hard to trust, and a team that cannot tell a good test from a passing one now has more of both. Day two looks at where the tools help the cycle and where they quietly break it.
Can two days be cut down to one?
They can, and what you lose is the second day rather than a compressed version of it. Day one builds the habit. Day two is where the habit meets databases, legacy code and the colleague who thinks this is a waste of time. Worth talking through on the call.
Who runs it.
In the roomGui Ferreira facilitates start to finish. He's been writing software since 2006 and is a Microsoft MVP. There's no junior trainer and no handover.
guiferreira.meThe other workshops.
Catalogue · 2Request this workshop.
10 questions, 3 optionalTell us about the team who'd be in the room. We read every one of these. If it's a good fit, we'll set up a 30-minute call and send a proposal within 48 hours of it. If it isn't, we'll say so.
