Looking for a creative way to inherit test cases

[John Arrowwood]

I have defined what kinds of tests need to be created under what circumstances.  For example, 

• the ID of a record does not need to be present on record creation, 
• if not provided the system will assign one, and it will look like a GUID, 
• if provided as a (unique) GUID, it works, 
• if the provided ID is a duplicate then record creation fails, 
• if provided something other than a GUID, it fails
• and once the ID is set, it can not be updated
  
• given an ID that exists, the record can be deleted
• attempting to delete an ID that does not exist will fail in a particular way

That's just for one type of field, I have tests for record name fields, generic string fields, numeric fields, class membership fields, timestamp fields, and so on.  A single record type might have between 100 and 300 test cases, in total.  And I have dozens of record types to test.

My initial attempt involved copy-paste-tweak.  That works, but it is problematic.  When I come up with another test case for a field type, I then have to make sure I implement it in all of the places where it applies.  I've been spending the last week or two trying to implement generic test cases, but I'm getting frustrated with the code complexity, and I'm afraid I'm going to end up with something that only I can maintain, if even I can.

What I would like is some way of saying, "here are a bunch of test cases" as a set.  Then in a test class, I want to be able to say "this is an implementation of that test set."  Then, any of the tests that I do not implement get defined as (pending) so I don't forget them.  Or, when I add a new test to the set, all of the test classes that implement that set suddenly have a new test case defined, which starts out as (pending) so it is clear that there is work to be done in those classes.  Alternatively, the classes no longer compile until the new case is added.

One way I can think of to implement this is to define all the tests as (pending) and then modify ScalaTest so that re-defining a test actually replaces its definition, rather than generating an error.  I strongly dislike that option for a number of reasons.

Another is to define a set as a trait, and the implementation of each test is a call to a function defined but not implemented in the trait.  Then the implementing class just has to implement the functions.  But I dislike that because it loses some of the beauty of the ScalaTest DSL.  

Are there any other creative ways of accomplishing what I'm trying to do?