Starting new project with TDD

Question

I'm studying TDD and I read that it also helps you to define the design of the app, correct?

So I decided to start creating a new project to help me understand it better.

I want to create a simple user registration system that will ask for its name, email address, country (will pick one from a list) and phone number.

So the question is...

I created a new solution in VS 2010, added a new Test project and I just don't know what tests to write!

Since it will help me define the design, what tests could I write here?

Thanks for any help!

Answer 1

When you write unit tests, you are testing the behavior of your application so the important question to ask is what does your application do? Here's a start:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

Answer 2

Just creating a test project and writing some test methods is a kind of TDD, but in my experience it isn't much help unless you are working on a library where there is a known API and method calls correspond directly to something expected by the user. You need to come up with the right list of tests, and for a non-trivial application, that can be really hard to do.

I recommend trying SpecFlow - it keeps defining tests nicely separated from the implementation and the structure of the feature files forces you to think about what you are actually testing.

When you define a feature you just write something like

When a user is saved
Then the user should exist

Because you aren't in a code file at this point, you aren't tempted to think about implementation details like which method gets called to create a user or even which class it is implemented in. You can use tags to choose different implementations, so at this level it doesn't matter whether "user is saved" means a call to CreateUser or opening a browser and submitting a form.

Once you have the features defined, all the tests are generated and will start to pass as you implement the step definitions and the actual application code being tested.

For a simple app you can just create the feature files, but for anything more complex it is useful to put together a more complete spec beforehand. I use an iPad mindmapping app for this, but you can use whatever tool you are most comfortable with.

Start with a list of high level features like "User registration". These tend to be too broad to write tests for directly, so break them into subfeatures that can be clearly defined and generally map to a specific user action like "Save user" or "View existing user".

Each of these subfeatures will need a list of scenarios that together completely define whether or not the feature is working, things like "Can save a valid user" and "Cannot save a user with duplicate username".

As you build this list it will generally become clear where the structure needs to be adjusted - if you can't come up with any scenario tests for a feature, or you end up with too many in one feature then that feature is probably defined at the wrong level and needs to be split or changed.

Answer 3

I found it good to back up my first experiments into TDD with some reading as well as cutting code. The wikipedia article on the subject is very good and will lead you a wide variety of other resources. Look for things by Kent Beck in particular - sort of the father of TDD.

Another things that might help you get in the swing of it is doing some katas - simple, almost mindless training exercises. Roy Osherove has some good ones.

Beyond that, just keep in mind the key ideas of TDD - write one test at a time and don't go on until it and all the previous tests pass. Only write enough code to satisfy the current test, avoid the temptation to write more. As you go, stop every now and again and think if you can clean up either the code or the tests. Always develop in a red (failing test), green (passing test), refactor cycle.

And to get you started, perhaps start with your name requirement. What are you going to need?

You will probably need a class. Write a test for that (some people skip this but when beginning do it for the exercise) and write the class.

Next your class will need to store a name. Write a test proving that your class indeed can. Then again write code to make the test pass.

Then perhaps you have some more business rules. Maybe you want your name to be a minimum number of characters long. Write the test, see it fail, write the code.

And so on...

Answer 4

I think it's not possible to give you the idea of TDD in a short answer. You need to "see" sombody practicing it, to get the feeling of it. The best resource I've ever found about that topic is http://pragprog.com/titles/achbd/the-rspec-book. Before you tell me, that Ruby is not your language: Read the foreword by Uncle Bob! ;-)

Answer 5

You may want to set up a test that tries to add multiple different values into the email field, some being valid and others not. Don't stop developing until all of the tests give the expected value. Stuff like that.

Answer 6

As you have described the system, there is only one test at the application level:

[Test] public void Save_and_retrieve_user(String name, String email, ...) { // Save // Retrieve // Verify }

As you refine the requirements, add more tests.