On 02/07/2014 11:59 AM, Ademar Reis wrote: >> 4b) Unittests for core code must not depend on system (i.e. external >> tools, configuration, or data) -or- repository state (i.e. higher-level >> module availability or present TP code/tests). These are key to early >> organizational problem detection. > > Agree that core could should never *ever* depend on TP code.
We should probably be even more super-duper clear here: The core should never *ever* depend on the implementation details or behavior of TP. However, it may (and often must) depend on a TP's following a core-defined interface very closely. >> >> 4c) TP unittests on the other hand, _SHOULD_ make liberal use of >> available code-code and unittests. However, dependence on system state >> is still forbidden. These are also key to early organizational problem >> detection. > > As long as there are no TP interdependencies, yes. I agree in principle, though these few words appear to hide a massive spider-web of work in practice :S I think it's the price we paid for having a large growing community, and promoting 'organic', rapid development. I think the depth and scale weren't fully realized until recently. > So depending on external configuration/tools/state is acceptable, > as long as the test is disabled by default and properly > documented. Most of the time, this is better than no test at all. Based on several actual experiences on the wrong-side of this, not having the unittest is more practical than disabling it by default. This is because when a unittest can't be segregated properly, it's often sign of massive underlying code interdependence / layering problems. In the spirit of 'get 'er done', re-writing the underlying code is often impractical, and then it's better to just skip that unittest and rely on CI catching problems. Otherwise you risk having to fix both the code and the unittests later. > > Although in practice I think what you've described will happen > naturally, I suggest we leave it out of the "rules" or "policy" I'd like to agree, and I hope you're right. I wrote those based on LMR's concern of "we had rules in the past, but nobody followed them". In the past, these kinds of fixup responsibilities seem to land on LMR's plate (and/or he's just a _really_ nice guy). I'm not sure if he or other maintainers have time dedicated for this or not. Rather it just seemed a valid concern worth mentioning. -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
