1

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?

w0051977
  • 15,099
  • 32
  • 152
  • 329

2 Answers2

4

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.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • I have asked a similar question here: https://softwareengineering.stackexchange.com/questions/364631/should-i-mock-a-domain-service. Could you take a look? – w0051977 Jan 24 '18 at 23:01
-1

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.

Nkosi
  • 235,767
  • 35
  • 427
  • 472
  • Please see this code here: https://github.com/jbogard/presentations/blob/master/WickedDomainModels/After/Model/Member.cs. Surely you would want to test that IOfferValueCalculator is working properly? – w0051977 Jan 22 '18 at 20:26
  • @w0051977 Yes that is a more complex value object with explicit dependencies that would benefit from unit testing. – Nkosi Jan 22 '18 at 20:27
  • Thanks. I was thinking about testing the AssignOffer method by passing in a concrete OfferType and ValueCalculator and asserting the Offer returned. Is this a valid test or should I be mocking the ValueCalculator? – w0051977 Jan 22 '18 at 20:44
  • @w0051977 Both can work. If you want more control of the expected behavior then mock the one you want to control. Any dependency that can be used without knock on effect can be used as is. – Nkosi Jan 22 '18 at 20:47
  • Thanks. If I mock the two objects passed to the class, then I realise it is a unit test. Is it an integration test if I pass two concrete objects to the method? This is my last question and is my original question. – w0051977 Jan 22 '18 at 20:49
  • @w0051977 You are focusing to narrowly on the terminology. If the intention is to test `AssignOffer` as the subject, then provide the minimal necessary dependencies to exercise that test to completion, If the objects passed are concrete does not necessarily make it an integration test. If you want granular control of the dependencies then mock them. I hope that answers your question. – Nkosi Jan 22 '18 at 21:02
  • Thanks. That's it. I have asked a question about Autofixture here if you are interested: https://stackoverflow.com/questions/48388861/should-i-be-using-autofixture-to-test-the-core-element-of-my-onion-which-has-no (I see AutoFixture is tagged on your profile). – w0051977 Jan 22 '18 at 21:05
  • Do you think it is worth doing both tests in my second comment or just one of them? – w0051977 Jan 23 '18 at 08:24
  • @Nkosi POCO's, entities and value objects are perfectly legitimate candidates for tests. They can contain a lot of logic. In reality, the domain layer arguably contains the **most important logic** in your system. – guillaume31 Jan 26 '18 at 09:55