TDD + DDD: Model abstractions

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.

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.

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.

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.