Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Im researching TDD, I'm not really sure how to write a test before I have written production code. The problem is that TDD states that you make assertions and then write your code so that these assertions pass. But You have not created any classes yet (as part of the production code) so how are you meant to write the tests if you dont have any classes with which to assert.
Hope someone can explain....
The first error that the test exposes is that using your API doesn't compile, because the class doesn't exist.
So you fix it so that the test compiles.
Then it will probably fail because the production code doesn't do what the test demands.
So you implement just enough of the class to make it pass.
Then you demand more sophisticated behaviour in your test.
Repeat again and again.
(Note: This is the orthodox, hardcore version of TDD. Opinions differ on whether it is really necessary to start with a deliberately uncompilable test, or how much business code to write between iterations. The extreme view is that more than 3-5 lines is always too much; others are more variable.)
You probably will start with a test that just instantiates a class. The compiler will emit an error because the class does not exist (red). To make the test succeed you have to create the class to test. The compiler will now run the test (green). Now you can, for example, call an nonexistent method. The compiler will complain (red). Create the method in the class, the compiler will stop complaining (green). Place an assertion in your test for the method. The test will fail (red). Extend the method such that the assertion works. The test will run (green).
Depending on what language and IDE you are using, you may have some support for "consume-first development".
e.g. in Visual Studio, you could write this line of code:
NewObjectThing foo = new NewObjectThing();
Now, you'll get the red squigglies to indicate that the type or namespace NewObjectThing cannot be found, and of course the code will not compile.
But if you right-click on it and select Generate -> Class, it will create a new file NewObjectThing.cs in the same folder & namespace as your current code, with an empty class declaration for NewObjectThing.
Similarly, if you then wrote:
foo.Name = "Fred";
..you could then right-click on Name and select Generate -> Property to add a property to the NewObjectThing class (and it would infer the type as string based on what you were assigning to it).
There are add-on tools like Resharper and CodeRush that add considerable flexibility and power to this process.
Anyway, have a look to see if your IDE supports something similar.
Another reason for writing a test before the code it's testing is written is to make sure the test fails. This ensures that you are actually calling the test and that it does fail. Sure, it's unlikely we would ever get that wrong, but .....
</sarcasm>TDD's purpose is to help you, not to beat you over the head with regulations :) When @Ikke says interface, BTW, they mean public interface (class methods/properties), not a C# or Javainterface.dynamickeyword and a factory function to return your class under test. This allows you to compile and run your test suite, even though methods or whole classes might be missing, and treat binding errors as runtime errors instead of compile time. This lets you write all the tests first, even before writing a single piece of code. There is a minor abstraction cost in your tests, so it is subject to taste.