Potential components of test suite
To create ConformanceTests you need a minimum of information
Test materials metadata
A test case must include:
-
test ID
-
test purpose
-
information on how to run the test suite
-
expected results of running the test suite – what constitutes a success
-
the test's review status (If the test has been declared valid by the group)
and may also include
-
author information
-
a brief description of the test
-
type of tests for those tests that have different types
-
a test prioriity
Be sure of what you’re testing
Whenever possible and sensible, write two test cases which differ by exactly the one thing you’re testing. The one not containing the feature or failure under test is the baseline. Only if the baseline works properly with a particular piece of software can you draw meaningful conclusions from the result of the actual feature/failure test case.
If you don’t do this, you won’t know whether a failing test case is failing for reasons unrelated to the feature/failure under test.
Comments
I suggest that the tests be documented with respect to the expected results. For example, TitleConformanceTests is perfect: viewing the feed tells you what the expected result is. LinkConformanceTests, OTOH, gives me no idea of what the author expected to see when viewing the entry in a reader. For example, what does the author expect to see when viewing the second entry? If I display only the second link, do I pass? Do I need to display both links to pass? -- GordonWeakliem
