What is the best practice to unit test the Aggregate Roots?

Imported from Google Groups
1

In my code I have separate classes for Aggregate Roots and Command Handlers. If I am unit testing all of my command handlers using GivenWhenThen fixtures, should i still unit test my Aggregate Root classes? If yes, what should be my goal to unit test the Aggregare Root classes?

I am thinking about improving my unit test coverage for the application(I have a goal to achieve 90% unit test coverage), hence this question!

Thanks and appreciate your response!!

2

The docs describe Axon’s support for testing aggregate classes: http://www.axonframework.org/docs/2.4/testing.html

3

Personally, I never write unit tests for my aggregates. The tests with the fixtures must be able to achieve 100% coverage. If not, you have unused code in your aggregate. Or are using your aggregates for queries, which is worse.

Cheers,

Allard

4

Hi Allard,

Exactly, you read my mind. I had the same thoughts, was just asking this question only from test coverage perspective. I think it will be 0% test coverage for the Aggregate classes, which (i believe)should be ignored as we have achieved the goal by testing using our fixtures. Correct me if am wrong. Thanks!

5

Why would coverage be 0%? The fixtures can be in the same module as the aggregate. The commands and events would have 0% (reported) in that case, but they don’t contain any logic anyway.
Cheers,

Allard

6

Hi Allard,
I’m wondering a similar thing.
I can understand, and I’m agree too, that fixtures cover 100% of aggregate code,
but what about the verification of the internal state of the aggregate after events applied?

For example, after I verified that ChangeUsername(“allard”) command fires UsernameChanged(“allard”) event,
how can I verify that now the username property of the User aggregate contains truly the value “allard”?

Thanks
Alessio

7

Hi,

short answer: you don’t!
motivation: the command model doesn’t expose state. So even if you had a reference to the aggregate root, there should be no way for you to access its state.

The only visible thing from an aggregate is behavior. So you don’t want to verify a field has the correct value. You want to test whether the aggregate shows correct behavior after changing a username. Ask yourself this: why do you bother storing the username? In your answer, you’ll mention a few commands and/or events. Those are the situations you want to test.
For example: when changing the username, and I change it to the same value again, the second change is ignored. Then test “given username changed”, when “change username to the same value”, expect “nothing”.

Cheers,

Allard

8

I’m not getting wrong, since that is exactly what I was doing.

thank you Allard