CODEWITHSUNDEEP
unit-testingdomain-driven-design
w0051977
w0051977

Reputation: 15807

Testing the Inner part of the Onion

I am building an application using DDD principles.

The first testing iteration was for the inner part of the Onion i.e. the Entities and Value Objects. This is not a Unit Test because there are no dependencies and I believe it is not an integration test because I am only testing one layer i.e. I am not testing how two or more layers integrate together.

Here is a diagram of an Onion: http://www.c-sharpcorner.com/article/onion-architecture-in-asp-net-core-mvc/. I am testing the Domain Entities only.

Therefore what type of test is it?

Upvotes: 1

Views: 1038

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57259

Therefore what type of test is it?

Typically, if you are testing the domain model (or parts of it) isolated from the application and infrastructure concerns, then what you have is a unit test.

There's not, of course, universal agreement on what a "unit" is; see for example Martin Fowler's discussion of solitary vs sociable tests.

But you might consider some of the popular examples -- the Bowling Game kata, and notice that much of the test first demonstrations in the Chicago style of TDD are fleshing out domain logic independent of application and infrastructure concerns.

There is usually nothing much to test in that layer. It comprises primarily of POCOs anyway.

That wouldn't normally be true of domain entities and domain values; if following the object oriented coding style, the interesting business behaviors are combined with the data into objects.

If you were following a more functional style, then you might end up with boring immutable data (which might be POCOs), and the interesting behavior to test would be expressed as pure functions.

But in either style, these behaviors would be part of the domain model, and therefore would live in the core of your onion.

Expressed is a slightly different way, the functional core of your application is normally unit tested.

Upvotes: 4

Nkosi
Nkosi

Reputation: 247098

There is usually nothing much to test in that layer. It comprises primarily of POCOs anyway.

If however, you have complex value objects that provide functionality and have explicit dependencies then there may be cause to Unit Test those in isolation by providing the minimal necessary dependencies to exercise those tests to completion.

Any dependency that can be used without knock on effect can be used as is. If you want granular control of the dependencies then mock them.

But other than that there is nothing else to actually test in the core.

Upvotes: -1

Related Questions