Should unit test classes be kept under version control with the rest of the code?

Question

If I create a test suite for a development project, should those classes be kept under version control with the rest of the project code?

Answer 1

Yes, there is no reason not to put them in source control. What if the tests change? What if the interfaces change, necessitating that the tests change?

Answer 2

Absolutely. Test classes must stay up-to-date with the code. This means checking it in and running the tests under continuous integration.

Answer 3

Yes they should. People checking out the latest release should be able to unit test the code on their machine. This will help to identify missing dependencies and can also provide them with unofficial documentation on how the code works.

Answer 4

Yes.

Test code is a code. It should be maintained, refactored, and versioned. It is a part of your system source.

Answer 5

Yes, all the same reasons you put production code in to source control still apply to any unit tests you write.

It's the classic who, where and why questions:

• Who changed the code?
• When did they change it?
• What did they change it for?

These questions are just as pertinent to testing code as they are to production code. You absolutely should put your unit testing code in to the repository.

Answer 6

Absolutely, they should be treated as first class citizens of your code base. They'll need all the love and care ie maintenance as any piece of code does.

Answer 7

Yes they should. You should be checking the tests out and running them whenever you make code changes. If you put them somewhere else that is that much more trouble to go through to run them.

Answer 8

Absolutely! Test classes are source code and should be managed like any other source code. You will need to modify them and keep track of versions and you want to know the maintenance history.

You should also keep test data under source control unless it is massively large.

Answer 9

Yes. For all of the other reasons mentioned here, plus also the fact that as functionality changes, your test suite will change, and it should be easy to get the right test suite for any given release, branch, etc. and having the tests not only in version control but the same repository as your code is the way to achieve that.

Answer 10

Absolutely. You'll likely find that as your code changes your tests may need to change as well, so you'll likely want to have a record of those changes, especially if the tests or code all of a sudden stop working. ;-)

Also, the unit testcases should be kept as close as possible to the actual code they are testing (the bottom of the same file seems to be the standard). It's as much for convenience as it is for maintenance.

For some additional reading about what makes a good unit test, check out this stackoverflow post.

Answer 11

Unit tests should be tied to a code base in your repository.

For no other reason than if you have to produce a maintenance release for a previous version, you can guarantee that, by the metric of your unit tests, you code is no worse than it was before (and hopefully is now better).

Answer 12

Yes for all the reasons above also if you are using a continuous integration server that is "watching" your source control you can have it run the latest unit tests on every commit.

This means that a broken build results from unit tests failing as well as from code not compiling.

Answer 13

Indeed yes. How could anyone ever think otherwise?

If you use code branches, you should try and make your testing code naturally fit under the main codeline so when you branch, the right versions of the tests branch too.

Answer 14

Of course!