• Extract a Domain Model from User Stories
• Use a Domain Model to create tests
• Use tests to write source code
• Explain the cycle of TDD and what is meant by Red, Green, Refactor

Your morning teacher will provide a demonstration before you start each section.

1. Extract domain models from user stories

2. Use the Red Green Refactor workflow to implement a solution

• Fork this repository and clone the forked version to your machine
• Open tdd-domain-modelling.sln in Visual Studio

When you run a test, it's either going to pass or fail. When it fails, you'll be presented with a big red stream of text. This is called a stack trace and, though intimidating, does contain some useful information.

One of the core skills of a developer is debugging stack traces like this. The stack trace details in which classes & files the failure happened, and gives you a line number at the end. Most of the lines in the stack trace are irrelevant most of the time, you want to try and identify the files that you're actually working with.

In the sample screenshot below, we've tried to complete the first step of the exercise but provided an invalid value. Then we run the test associated with it and we see a big red stack trace, a test failure.

At the top, we see expected: 512 but was: 0. This means the test expected the value to be 512, but the value the student provided was 0.

In the stack trace itself, we see this line: 1. at csharp_fundamentals_primitive_types.Test.CoreTests.twoShouldBe512() in C:\Dev\boolean\csharp\fundamentals\csharp-fundamentals-primitive-types\src\csharp-fundamentals-primitive-types.Test\CoreTests.cs:line 17. This is helpful! This tells us the exact line in the CoreTests.cs file (line 17) where the failure happened, as well as the method name (twoShouldBe512), helping us to identify where the issue began. This is the kind of thing you need to look for; a relevant file name, method name, class name and line number to give you a good starting point for debugging.