TDD + DDD: Model abstractions

Question

I've recently had an interesting experience but didn't find a satisfying answer so far: I'm a big fan of DDD and try to define rich domain objects with behavior and good information hiding, even if the team officially doesn't practice DDD. At the end of the day, it doesn't matter, as you have a well-defined object, which represents something in the problem domain.

That said, I would also like to practice TDD more. Unfortunately, if I test a service, which uses such rich domain models, the models are usually not abstracted. Therefore, to test the behavior of the service, I need to set up the model as well. This model comes with its own invariants etc., therefore with every service test, I also test the model the service is using.

This seems like a big no-go, as I'm not only "not really unit-testing", but it's also troublesome to set up the tests, as the arrange-code gets large. In my opinion, there seems to be no way around this but to start creating interfaces for models. But it seems like I am the only person thinking so. For example, here is a big article, why this is an anti-pattern: https://lostechies.com/jamesgregory/2009/05/09/entity-interface-anti-pattern/

I’m also not that too delighted to create interfaces for all models, as they should really represent something and adding another layer of abstraction just for testing seems like overkill. That said, what would be the best solution hereby? How are people on the field, which do combine DDD and TDD, handling this?

Answer 1

I had a similar challenge and, together with my team, we created a tool that simplifies the test data arranging process by employing a random data generator: https://github.com/ocadotechnology/test-arranger. Especially take a look at:

• How to organize tests with Test Arranger as it explicitly refers to the common DDD building blocks and explains how to arrange test data around them. In my case, following those recommendations resulted in a significant reduction in the amount and complexity of code for preparing the test data.
• Custom Arrangers as it shows how to deal with the model invariants.

Besides the recommendations given on the test-arranger page, it is also handy to use Lombok's @Builder(toBuilder = true) (or an equivalent like Kotlin's copy method from data classes) on your domain classes. With the toBuilder method you can easily adjust randomly generated value objects and entities to the needs of a certain test case.

Answer 2

First I will make sure these two conditions are meet:

• Domain models are POJOs
• Domain layer isolation (other layers can access domain layer but not the way around)

Then Factory, Builder or TestHelpers can be used to bring models to desire state for tests.

Answer 3

This seems like a big no-go, as I'm not only "not really unit-testing", but it's also troublesome to set up the tests, as the arrange-code gets large.

I think you can dismiss "not really unit-testing"; the important thing is to use tools that are fit for purpose, not the branding.

That said, troublesome to set up the tests is a legitimate concern, and all by itself sufficient excuse to look for a way to improve the design.

If your service were tightly coupled to some third party implementation, that offered no affordances for substitution, what would you do to decouple that from your tests? The usual answer would be to introduce a seam - a new design element between your code and the 3rd party code.

The two important characteristics of the seam:

• it does afford substitution; which is to say, you have an interface.
• the implementation of the interface that integrates with the third party code is "so simple there are obviously no deficiencies".

Then, in your tests, you introduce a substitute implementation.

The game with your "domain model" is exactly the same. Assuming that you are applying the usual lifecycle patterns, the seam includes a substitute for the repository and a substitute for the aggregate root entity.

Some good news - you only don't necessarily need to shadow the entire aggregate: only the parts of the interface that your service cares about. In effect, what you are doing is defining - for each service - the contract that describes the interactions between your service and the domain model. "Role interfaces" will be a useful search term here.

Answer 4

Basics

Testing Scopes

• Unit Testing
• Integration Testing

Domain Models

• These should be unit tests, which tests the Domain Models / Aggregate's methods.

Services

• These should be integration tests, which tests the integration of Service methods and the associated models.

---

My Broad Approach

When you're testing your domain models, there may be many variance, that you'll need to account for in your unit tests.

When these then translate over to a requirement to use within an integration test, I tend to go for some sort of CreationFactory (or ArrangementFactory) for your domain models.

You can then use these in both sets of tests.

So for example...

public class ArrangeUser {
  public static User ArrangeStandardUser() {
    return new User(...standard...);
  }

  public static User ArrangeAdminUser() {
    return new User(...admin...);
  }
}

Then in your Unit Test...

// Arrange
User standardUser = ArrangeUser.StandardUser();

// Act
bool canDoSomething = standardUser.CanDoSomething();

// Assert
Assert.True(canDoSomething);

Then in your Integration Test...

// Arrange
User standardUser = ArrangeUser.StandardUser();
ServiceToTest service = new ServiceToTest(standardUser); // replace with some sort of Repository Mock or whatever suits.

// Act
var bool canDo = service.CanDoService();

// Assert
Assert.True(canDo);

This way you can test both the unit aspect, and the service aspect - by creation a common way to create the arrangements, without having to abstract out the entities and solves the problem of recreation the same thing over and over again.

NB. This is just a basic code demo than can be made more complex, based on the scenario, or your preferred test style.