Test Driven Development - What exactly is the test?

Question

I've been learning what TDD is, and one question that comes to mind is what exactly is the "test". For example, do you call the webservice and then build the code to make it work? or is it more unit testing oriented?

Answer 1

Here are a couple of good articles by Unclebob

Three rules of TDD

TDD with Acceptance and Unit tests

Answer 2

It's entirely Unit Test driven.

The basic idea is to write the unit tests first, and then do the absolute minimum amount of work necessary to pass the tests.

Then write more tests to cover more of the requirements, and implement a bit more to make it pass.

It's an iterative process, with cycles of test writing, and then code writing.

Answer 3

Here's an answer made by a known member of the community on his blog. It should help you getting it.

Answer 4

In general the test may be...

• unit test which tests an individual subcomponent of your software without any external dependencies to other classes
• integration test which are tests that test the connection between two separate systems, ie. their integration capability
• acceptance test for validating the functionality of the system

...and some others I've most likely temporarily forgotten for now.

In TDD, however, you're mostly focusing on the unit tests when creating your software.

Answer 5

I suggest you not to emphasize on Test because TDD is actually is a software development methodology, not a testing methodology.

Answer 6

I would say it is about unit testing and code coverage. It is about shipping bugless code and being able to make changes easily in the future.

See Uncle Bob's words of wisdom.

Answer 7

How I use it, it's unit testing oriented. Suppose I want a method that square ints I write this method :

int square(int x) { return null; }

and then write some tests like :

[Test]
TestSquare() 
{
Assert.AreEqual(square(0),0);
Assert.AreEqual(square(1),1);
Assert.AreEqual(square(10),100);
Assert.AreEqual(square(-1),1);
Assert.AreEqual(square(-10),100);
....
}

Ok, maybe square is a bad example :-)

In each case I test expected behaviour and all borderline vals like maxint and zero and null-value (remember you can test on errors too) and see to it the test fails (which isn't hard :-)) then I keep working on the function until it works.

So : first a unit test that fails an covers what you want it to cover, then the method.

Answer 8

Generally, unit tests in "TDD" shouldn't involve any IO at all.

In fact, you'll have a ton more effectiveness if you write objects that do not create side effects (I/O is almost always, if not always, a side effect!), and define your the behavior of your class either in terms of return values of methods, or calls made to interfaces that have been passed into the object.