57

I'm a growing programmer who's finally putting unit testing into practice for a library that I'm storing on GitHub.

It occurred to me that I might include the test suites in the repo, but as I look around at other projects, the inclusion of tests seems hit-or-miss.

Is this considered bad form? Is the idea that users are only interested in the working code and that they'll test in their own framework anyway?

Improve this question
6
  • 13
    Why not? Tests should come along with the project or they are barely useless.
    – user2567
    Commented Jan 5, 2012 at 9:43
  • 68
    The fact that some project don't include unit tests in their repository is more likely due to non-existence of these tests in the first place.
    – brabec
    Commented Jan 5, 2012 at 10:39
  • 4
    They are built separately, but otherwise u-tests are tightly coupled with code. To ensure consistency there must some kind of dependency management. Be it putting them into same repository, subrepository or maintaing version controlled "link" to test repository, etc.
    – MaR
    Commented Jan 5, 2012 at 11:03
  • 2
    Note, that I would consider it a good idea to disable test class compilation in your build script.
    – user606723
    Commented Jan 5, 2012 at 15:31
  • 2
    Once/If you start using CI, where is the CI server going to get the tests from?
    – Steven Evers
    Commented Jan 6, 2012 at 18:23

7 Answers 7

Reset to default
123

You definitely should put your tests into the repository. Tests are in my opinion part of the code and can help others immensely to understand it (if well written). Besides, they can help others when changing or contributing to your codebase. Good tests can give you the confidence that your changes do not inadvertently break anything.

The test code should be well separated from production code, though. Maven for example achieves this by putting production and test code into different folders. The question "is this file part of production or of the test code" should never arise.

I personally do not write unit tests for used libraries in my own code. I expect them to be working (at least when I use a release version, though bugs obviously can appear). It gets some test coverage in integration tests, but that's not enough.

Improve this answer
2
  • 1
    As another example, take a look at ipython's testing folder. If someone checks it out, no matter where they put it, the relative links for the tests are still true. It makes it trivial to test it, which is important for determining if your new dev machine is configured properly.
    – Spencer Rathbun
    Commented Jan 5, 2012 at 20:27
  • Tests are not only part of the code, but also part of the documentation, and often part of the spec. Tests (which run and pass) are "living documentation".
    – Michael Easter
    Commented May 3, 2014 at 12:41
54

If you don't include the unit tests in the checked-in source code, then:

  • how is someone who downloads and builds their own copy of that code going to verify that it's working the way it was intended? Compiler and library bugs are rare, and data errors (particularly ones that don't render the source code impossible to compile) are even more rare, but they definitely can crop in, particularly when you cannot dictate the build environment to the degree that an employer can dictate which tools are used.
  • how are you going to get the tests back if something happens to your local copy of the source code?
  • how is a new developer going to verify that their changes doesn't break anything in the existing code base?

Bottom line, I would consider not including any unit tests written in the official source code repository a very bad thing.

Improve this answer
8

Of course you should put unit tests into the repository, for several reasons:

  • it is easy to revert to previous version
  • other people working on the project also gain access to unit tests
  • some people consider unit tests as part of the documentation (TDD and BDD)
Improve this answer
6

If there is any chance to run them on another computer, definitely include them. They should be built separately, so users don't have to, and they may have extra dependencies, but they should be definitely included.

I'd strongly suspect most projects that don't include tests in the repository simply don't have any.

There may be a reason to have the tests as separate module, so you can easily run new tests against older code. It would be useful for API-stable library or black-box tests via command-line; usefulness for compiled languages where the new tests probably won't compile with older code is limited.

Improve this answer
5

Absolutely. The extra bonus points here are in the ability to track that version X of a source file goes with version Y of a test. In other words, you need to be able to go back to a previous version and pull the appropriate tests designed for that version (in case of an API change or somesuch).

Improve this answer
3

I've just finished reading "Brownfield Application Development in .Net", and this provides some excellent advice of the structure of an application, including source control and where/how/why to include unit tests (particularly in the area of Continuous Integration). If you're a .Net developer, I'd recommend it.

Improve this answer
2

The reason why you aren’t seeing the test in those repos, is almost certainly because there are no tests.

In so much as you have test, part of the point is the ability to get the code, run tests, and say all is good and you are starting at the same point as everyone else.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.