From the why-didn't-I-think-of-this-before-now dept: There's usually a point on every project where you move out of your here's-how-we'll-do-persistence phase, where you build your prototyping around one or two entities, to the harder-core implementation phase where you start essentially copying and pasting and renaming to create your 50 entities. Getting better reuse out of the actual entity classes, and whatever your DAO-type functionality is, is a topic for another day (this is where Nanning mixins shine). If you're doing Test-Driven Development, (where possible) you need to write a test in order to give your mainline code permission to exist. Rewriting test code for each entity, that demands it have create, update, delete, etc functionality is tedious and results in a huge set of code that in and of itself has a certain inertia that discourages change. I made an abstract class called EntityTestSupport which extends TestCase, and has a constructor which takes a Class as a parameter. Then I make a test for each entity which extends this superclass, feed in the entity class as the parameter to the superclass constructor, and inside my superclass I run the entity through a bunch of common tests using naming standards and reflection. For entity X, I have XFactory, which has methods newX, getXById, removeX, etc - and inside EntityTestSupport, I have tests that flex each of these operations. This is great from a TDD perspective, because merely extending the superclass and feeding in the name of the next entity I want to create, creates a demand for a new fully-featured entity type. And in the concrete test class you can obviously write tests specific to that entity. Pretty neat....
Previous Topic
