Given a class that inherits from ActiveRecord::Base, lets call it Task, I have two subclasses that specialize some aspects of a task, Activity and Training, using standard Rails single table inheritance.
I’m confident in that choice after looking at other available since the actual data for the models are the same, it’s just the behavior that differs. A perfect fit for STI.
A task can be created, started, progressed and finished. That is some logic involved in these transitions, especially start(), that calls for the specialization of the base class.
Since I’m doing this TDD and started out with a working Task calls with full test coverage I’m now wondering how to proceed. I have a few senarios that I have thought about:
-
Duplicate the tests for Task and test both Activity and Training end to end with some small modifications to test their specialization. Pro: it’s quick and easy. Con: it duplicates code and while that might not be a big problem here it will be when the number of specializations grows.
-
Split tests and keep most of the testing code in a
task_spec.rbwhile moving specialization testing into new specs for the respective subclasses. Pro: keeps the tests DRY. Con: what class do I instantiate in the base test?
That last question is what is nagging at me. Right now I have the base class test set up to randomly create a class from one of the concert subclasses, but is this good form? It almost makes me want to go with approach 1 just to keep the test runs consistent or I’ll have to find a way to base the randomness of my class selection of the random seed for the test suite so that I at least have a repeatable random selection.
I’m guessing this must be a common problem people run in to but I can’t find any good information on the subject. Do you have any resources or thoughts on the matter?
You could use rspec shared examples to test the behavior that is shared among all of them (basically, the inherited behavior, or places where you want to guard against LSP violations).