Continuous Integration has always to come together with Test Driven Development?

Question

I'm involved in a project where we are using a Continuous Integration server and NUnit for unit testing and integration testing.

A customer asked us the other day if we were writting the tests before the code... Well, were are not doing it this way always. Specially when there are complex technology issues that we would like to test to understand the problem and the possible solution first.

I would like to know if we could still considered our development process as following Agile Development, say it to customers and don't lie.

Answer 1

As long as you are developing in small iterations, focus on getting a working product rather than on getting extensive documentation, and the customer is continuosly involved in the project, it is agile development. Unit testing, TDD and integration testing are of course good and very advisable practices, but they do not decide whether your project is agile or not.

Answer 2

I think you are mixing up things here.

Test-Driven-Development (TDD) does not necessarily mean you are using an agile approach. Surely, it is a best practice that many of us who do agile use, but TDD can also be used in a Waterfall process, replacing/supplementing the specification.

Continous-Integration on its own means having the code your team produces integrated on an at least daily basis. This does not only force every member of the team having to merge/checkin continously, but also assures you actually can do a release of every build.The unified build process forces you to overcome the "works on my machine syndrom". Because you could do a release everyday this supports an agile process, even though it is not absolutely necessary in the strict sense.

Using tests and integrating them into the build process is a way to enrich your buildprocess with automated Quality Assurance and deepen the level on which integration (integrity) is actually tested.

Answer 3

In the absence of Automated tests, CI only verifies that the code under source control is maintained in a compilable state between revisions and that the single-step build works properly. While this is useful, it isn't as useful as the automatic verification that the correctness of the code has been maintained between revisions.

With that said, I'd rather have some verification of code between check-ins than none. I'd rather have partial code coverage or an incomplete set of functional tests than nothing. Or worse.