Object Mother

As described by PeterSchuh on IeeeSoftware: Through a handful of simple method calls, this utility provided a complete, valid, and customizable structure of business objects (think of an invoice: its lines, all related charges, remit to, bill to).

ObjectMother starts with the factory pattern, by delivering prefabricated test-ready objects via a simple method call. It moves beyond the realm of the factory by

1. facilitating the customization of created objects,
2. providing methods to update the objects during the tests, and
3. if necessary, deleting the object from the database at the completion of the test.

Some reasons to use ObjectMother:

1. Reduce code duplication in tests, increasing test maintainability
2. Make test objects super-easily accessible, encouraging developers to write more tests.
3. Every test runs with fresh data.
4. Tests always clean up after themselves.

The latest paper available on this topic can be found at http://www.junit.org/news/article/patterns/ (http://www.xpuniverse.com/2001/pdfs/Testing03.pdf).

---

Has anyone tried this pattern in practice? What was your experience? It appears to be geared mostly towards mutable objects.

---

Yes, the pattern is not as elegant as intended with ImmutableObjects. If your objects are void of setters, you are driven towards having multiple factory methods that create instances of your test object. These factory methods have to take all the variant parameters in their method signature. This is not entirely bad, but it can leads to having a fairly long list of chained methods. In a way, it sounds like the original white paper calls for setters as part of the contract for this pattern. Thus, ObjectMothers with ImmutableObjects is probably diverging from the pattern.

Another problem I've run into is with ObjectMothers that call other ObjectMothers. If you're not careful to minimize your TestGranularity, this can lead to a DebuggingNightmare.

-- JavidJamae

---

We use this pattern in testing. It is good because we can create the User object and then set state on it. Usualy you need to pass access permisison tests to change certain fields. With the ObjectMother pattern we can fiddle with the insides of the object. -- R. Keene

---

Actually this should be called an AntiPattern. In practice all those I've seen that have advocated this approach return shamefaced a few months later. This pattern is a bit like the other well known pattern "putting everything in one place" (GodClass), and what it is that is actually being created is quite non-obvious. The BuilderPattern might be more useful... -- J. Richardson

---

My experience is different. Could you elaborate a little more? What issues did you encounter with them (outside the Immutable problem)? -- J. Morel

I guess the problem is that you end up having a ObjectMother that is also a GodClass, it has too many responsabilities... becomes huge and hard to mantain (BigBallOfMud)... perhaps the right answer is to have a different ObjectMother for each ObjectChild? class? (but then you might end up with RavioliCode)

The problem is that ObjectMother does not cope well with variability in the test data being created, except by allowing the user of the objects to modify them. That doesn't work if the ObjectMother creates ValueObjects (because ValueObjectsShouldBeImmutable). I've found it better to use the TestDataBuilder pattern (see: http://nat.truemesh.com/archives/000714.html).

I have been thinking precisely about this for the last 2 days, trying to find a way to escape from the GodObjectMother?... thanks a lot for finding (or writing) that ( Test Data Builders: an alternative to the Object Mother pattern ) article.

---

Yes, stop building God classes: I guess the problem is that you end up having a ObjectMother that is also a GodClass, it has too many responsabilities... becomes huge and hard to mantain (BigBallOfMud)... perhaps the right answer is to have a different ObjectMother for each ObjectChild? class? (but then you might end up with RavioliCode)

CategoryPattern, CategoryTesting