Why should I combine code and tests in a single commit?

Question

Let's say I write an atomic change of code. I also write some tests to make sure the change works and keeps working.

I think I should commit the code change together with the tests.

PRO:

• This makes sure (as far as possible) that every changeset of the branch results in running code and passing tests.
• It documents that these tests "belong to" the code change that I did.

CON:

• I may want to backout the change without backing out the tests some time in the future

What reasons more are there for doing it one way or the other? Has either strategy ever bitten you? How exactly?

Somewhat related: Should change to code be committed separately from corresonding change to test suite?

Answer 1

My only rule is to make sure that code builds prior to checking in.

Yes, ideally you want to check in atomic bits of code. However, how do you define atomic? And then what happens if, later, you have to change one of the bits? Your changes are no longer in one commit.

Answer 2

I think I should commit the code change together with the tests.

I never do, but I would, if I used a non-branching SCM.

In branching SCMs (I've worked with mercurial and git) it's a non-issue.

I use a different branch every time I start working or something; I many times have local branch commits that just commit outstanding changes (that don't even compile) when I move to something else for a while, or when I just need a backup point before I start a major code change). I know that most of those intermediary commits will never be checked out again, when I create them. They don't affect anything though and are really useful when needed.

I only merge branches back when I have code that compiles and tests that run successfully on it.