number of model tests

We have 173 assertions that test the validity of and document the
implementation of the features of the Web Annotation Data Model as described
in Sections 1 -4 (i.e., everything except collections and pages). 
 
These 173 assertions have been organized (see below) into 10 tests.
Associated with each test is a Web form into which an implementer must paste
her or his annotation when running that particular test. Tests can be run
individually, but when running the complete suite of tests, the current
organization means that implementers will need to paste the same annotation
into 10 Web forms that open and close sequentially, one after another. The
question came up this week whether we might want to reorganize the
assertions into fewer tests. This is extremely easy to do, and can still be
done, if we do it right away. 
 
Should we? If so, how should we reorganize our tests? 
 
Current Organization of assertions.
 
Currently, the assertions are organized into tests along two-axes:
 
- the type of assertion: validation check (56), implementation check (117)
- the top-level annotation object involved: i.e., annotation,
annotation-agent, body, target, body/target-agent, specific resource 
 
So, there is the annotationMusts.test, the annotationOptionals.test, the
annotationAgentOptionals.text (note, Agents have no Musts), the
bodyMusts.test, and so on. The current organization of tests allows users to
selectively test, e.g., run only the Annotation-level tests
(path=/annotation-model/annotations/) or run only the validation checks
(check the use_regex box and path="/annotation-model/.*/.*Must"). So the
questions are:
 
- whether this flexibility is worth it?
- whether a fewer tests approach - e.g., allMust.test (56 assertions) and
allOptionals.test (117 assertions) - would scale, make more sense to
implementers, and work okay with the test runner software?
 
Thoughts?
 
Thanks,
 
Tim Cole