>So an assertion contains exactly one testable, either it is a requirement or a test case. Is this the model you are thinking of?
>
The problem with this is, how do you know when an assertion about a requirement and an assertion about a test case are assertions about the same?
It would be really helpful if the assertions have something in common to allow comparisons. Because of the fact that we can't expect everybody publishing their test cases, maybe it should be the requirements.
So it could be:
- No Testable class
- At least one required Requirement per Assertion (an Assertion could be related to several requirements e.g. WCAG, 508 and mobileOK)
- An optional (just one) Test Case per Assertion
Regards,
CI.
>Johannes Koch wrote:
>>
>> Charles McCathieNevile wrote:
>>
>> [TestRequirement and TestCase subclasses of Testable]
>>
>>> I still think this is a bad idea, since I don't see the value in
>>> having the two kinds of subClass. If we adopt this, the range of
>>> earl:requirement needs to be made earl:Testable too. (Since we are
>>> shifting the range to a superclass, I think we can get away with that.
>>
>> If the object for the earl:testable is either an earl:TestRequirement or
>> an earl:TestCase we can create both assertions about subjects
>> passing/failing/... a certain test case or meeting/not meeting certain
>> requirements.