I think that this is the current structure (as I have reverse-engineered it) of the Litmus database.
I am proposing this, which I think will be much more flexible and will scale better in the long run. I am seeing a few slight errors, such as that there should be "0+" resources associated with a test, not "1+". But I think this is mostly correct.
The Category entity and its self-link allows a flexible categorization of the tests, but also allows a heirarchical categorization at the same time. The Resource entity would allow us to capture, for example, a URL as one resource of a "go to site of URL" test. Then associating 100 URLs with that test would be more flexible than creating 100 tests of the form "go to URL A", "go to URL B", etc. The Config entity would capture the type of machine and the versions of what is being run. This would be more flexible than, for example, creating a one version of test for Firefox 1.5, then a separate copy of the test for FireFox, then a separate copy of the test for Firefox 3, and so on.
If anyone has suggestions, please let me know.
1 comment:
I think that this is the current structure (as I have reverse-engineered it) of the Litmus database.
No need to reverse-engineer, the schema is in CVS: mozilla/webtools/litmus/schema.pl
I am proposing this, which I think will be much more flexible and will scale better in the long run...
We discussed this when initially redesigning the database for Litmus. QA staff were asked whether they needed to be able to create arbitrary levels of hierarchy for grouping testcases, but decided that the three-level mapping of testgroups->subgroups->testcases was well-suited to the kinds of manual testing they were accustomed to.
I don't disagree that your system is more flexible, but that's not something that we did need, or even need currently.
This would be more flexible than, for example, creating a one version of test for Firefox 1.5, then a separate copy of the test for FireFox, then a separate copy of the test for Firefox 3
Again, this was presented during the design process as one of the reasons why we might want arbitrary hierarchy. The QA team surmised at that time — and the Firefox 1.0->1.5 transition bore this out — that the underlying interface and functionality being tested by a given testcase changes enough from one major release to the next that testcases need to be essentially rewritten anyway.
There is already a linkage table in the database that tracks which testcases are cloned from each other. Not ideal, but it does let us track some basic testcase lineage. A more useful schema change, IMO, would be proper testcase versioning since we can't currently track changes for auditing purposes.
FWIW, we will be getting some type of arbitrary associations when we implement testcase tagging. This can be easily layered on top of the existing app, and is much lower effort than re-architecting the whole structure which we don't have an allocation for anyway. But hey, this is open source: now accepting patches! ;-)
Post a Comment