How do you handle TDD in the continuous integration?

Question

Imagine you are implementing the user story containing various new features and adding complexity to the code base. The existing code is quite well covered and you have just decided upon interfaces. You are starting to implement the functionality starting with tests.

Now you have fairly complex test cases based on the requirements but the implementation is nowhere near the point when you are able to commit to the SCM fully working code and many test are failing (as they should).

There is an assumption that in continuous integration all builds should be green if possible and thus you shouldn't commit as you would break the build. But you also shouldn't "Go dark" and keep such amount of code for yourself...

What is the suggested procedure in such situation?

Answer 1

Do not decide on all interfaces beforehand. Develop incrementally in a typical TDD rhythm: write a test; make the test pass; refactor. That should keep everything in good shape, the bar will always be green and you can check code in without worrying that you will break the build.

It requires a different style of writing code, but you will get used to the rhythm eventually.

Answer 2

What about skipping those tests that you know won't pass because the functionality is currently missing?

Make it obvious that you are skipping the tests too! Really make it scream "like a stuck pig", as they say in Oz! (-:

As you add functionality, enable the associated tests and keep "your bar green!"

Here's another great article over at The Pragmatic Programmers that covers making broken windows obvious to others.

HTH

cheers,

Rob