Testing And SCM

In my opinion, testing is something that can be audited, just like building. And if it produces a result (a report of some kind), it may be avoided, if attempted again in a situation in which nothing has changed. I.e. it can be identified, and shared. In short: managed.

Under ClearCase, the ultimate test report, derived object produced at the end of a test run, and to which gets attached the top most configuration record of the whole auditing hierarchy, including thus the build record, is the best possible object to use for applying a label (with mklabel -con <report>). This label, will thus get applied to every version directly or indirectly involved, propagating the information about the test script (including the build script), and the test result, to every developer who might want to later modify any of these versions.
(Note how this use of labels is completely by-passed by UCM, which shows thus up as a radically inferior process. Hence don't use it.)

This is especially valid for so-called regression testing, but it supports very well, IMHO, the kind of testing promoted by Agile methodologies: setup first your test cases, and implement only next.

I wish it would extend to multi-site cases, but this is not supported by ClearCase as per now. Supporting it would require some kind of late identification. [Some ClearCase users are requesting replication of derived objects, but I believe this is a bad idea: better to identify afterwards the results of local auditings on different sites, thus supporting alternative ways to reach the same results.]

Since ClearCase offers with dynamic views a virtual workspace which is managed implicitly, and once you play with its rules, you do not need to explicitly take the binary from the SCM: it is already there. There is no boundary. Everything is under SCM.

-- MarcGirod - 01 Jan 2008