Hi, I'm trying to get a concensus of what people do with regard to unit tests and sub (or external) projects.
I'll, hopefully, clarify with an example. I have a project P1 that relies on another project P2. P2 has its own unit tests and release cycle. P1 has its own unit tests as well. The question is should the unit tests for P2 be included/ran as part of P1's unit testing or should P2 unit tests be ran only when P2 is being release?
Clear as mud. Keith.
Run them when doing the get. If the code is being retrieved live from the source code control, then do run them as well. Also note that you might want to throw in some integration tests as on P1 regarding the use of P2.
I had similar experiences in the situation of client and server. i.e. client vs web service. Unit testings had been in place for both of the components.
P2 tests is based on assumption that P1 is solid. It is good idea to run against P1 release. But it doesn't hurt to run P2 and P1 to find more potential problems.
There's no need to run P2's tests when P1's are run. If P2's code hasn't changed, running the tests again during would provide no benefit.
If P2 breaks because of P1's tests, then more unit tests for P2 are required to ensure you have sufficient coverage (or perhaps you have an interface problem, which is a different issue entirely).
Theoretically, if the unit tests for P2 are good, then you shouldn't need to run them.
However, if you do run them, there is a (maybe slight) chance that you will make them fail, through a difference in environment. If the cost of running them is low, why not? If however, the setup for the tests is complex, you need an extra database or something, then it's maybe not worth the pain.
What you may need are integration tests for the code that uses P2 that tests for the behaviour of specific functionality that you use. If you're using P2, and P2 changes in some subtle way, then how do you know. If P2 has different release cycles, then this is especially important: you don't know what they've broken :-)