2

Should unit tests be included in the same repo as the tested code?
Or should they be in their own repo?

My contrasted thinking:
On the one hand, test code should not be in the same tree as production code; On the other hand, a single repo should be self-contained. (Though I admit that I'm still relatively new to DVCS in general, Mercurial in particular, Kiln to be precise).

AviD
  • 12,944
  • 7
  • 61
  • 91

1 Answers1

3

If you have different set of files which are strongly linked together (i.e you cannot change one without potentially having to change the other), those 2 sets belong to the same repository.

That way, the same tag applies to both, and they are always in sync.

"production code" is just a description of a stage in the development lifecycle: see "How do you maintain development code and production code?".
It doesn't prevent having other related set of codes (like unit tests).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you, but I see 2 issues with this: `If you have different set of files which are strongly linked... belong to the same repository` this rules out having a seperate repo for individual components - which I understand to be best practice in DVCS, no? Second, this doesnt relate to the first part of my dilemma, that test code should be seperate - not because of the lifecycle stage, but rather "code that is not to be deployed". I.e. all *supporting* code, such as test code, build tools, etc should all be outside of the "real" code tree. – AviD Mar 31 '11 at 08:36
  • @Avid: "individual components", with "individual" being the key word here. If you cannot change one set without having to change the other, those aren't so "individual" anymore ;) And I wouldn't consider a source code database like a VCS as a candidate for deployment: you don't deploy code. You deploy deliveries (artifacts: compiled version of the code, config files, ...). – VonC Mar 31 '11 at 08:52
  • Yes, of course you dont deploy the repo or code... I meant the code that gets built, and then deployed. "Individual", what about a shared component, which other repos' code has references to? The shared component should be in it's own repo, but if you change it you might need to change the relying code too. No? What am I missing? – AviD Mar 31 '11 at 09:04
  • @AviD: you can easily build your artifact with only the "right" subset of your code database (i.e. the one without any unit tests code). As for a shared component, it can be in its own repo... with its own set of unit test code. – VonC Mar 31 '11 at 09:11
  • Sorry, I think I'm not being clear with my issues: changes to SharedComponent can require changes to other code, but yet it is still in a seperate repo - contrary to what you said "if changes to one causes changes to the other, they should be in the same repo". – AviD Mar 31 '11 at 09:15
  • Second, there are good reasons to keep "buildable" code in a seperate tree from "supporting" code. Its not about building the right artifacts... – AviD Mar 31 '11 at 09:16
  • @AviD: in that case, where a shared component is reused, yes, one repo per component is appropriate even though modification to one means modification to others. The key difference with a source code and its unit test is the kind of dependency linking the two set of codes. With unit test, it is an internal dependency (unit tests aren't visible or reused by any other component) and in some case bi-directional dependency (some modifications you add in unit-test, especially in a TDD mode, will have impact on the source code). – VonC Mar 31 '11 at 10:31
  • @AViD: a separate tree can means separate branch within one repo, not necessary separate repo. – VonC Mar 31 '11 at 10:32
  • @VonC, thank you - your comments did help clear this up for me. – AviD Mar 31 '11 at 11:01