Unit testing CQRS

[Thomas Oellrich]

Hi all,

I'm new to CQRS. We're currently attempting to use it in a green-field project. I was wondering about unit tests. Since the aggregates on the write side are not supposed to have getters how do you write unit tests for them? Using reflection seems to be an option but is a PITA when doing refactorings. Any suggestions?

Thanks in advance.

Tom

[Angel Java Lopez]

My first, quick and only aswer ;-)

Unit Tests check the events raised.

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

[Thomas Oellrich]

Interesting. So you wouldn't actually check that the state of the aggregate has changed?

2011/5/26 Angel Java Lopez <ajlop...@gmail.com>

[sami.d...@gmail.com]

What about testing their behavior instead of their state ?

If a given state has no implication on future behavior, then why would you even keep the state in the first place ?

Sami

[Greg Young]

Nope. You don't need to and binding your test to the internal state
makes for brittle tests.

I am doing my talk at DDD Exchange on these testing styles.

--
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

[João Bragança]

No need to. Since the only point of keeping state in an AR is to affect the application of future events, all you need to test is what events come out of it. E.g.:

Given the order was placed

    And the order was paid for

When I ship the order

Then the order should have shipped

Given the order was placed

    And the order was paid for

    And the order was shipped

When I ship then order

Then it should throw an exception

# or, Then it should do nothing

# etc

So in this trivial example the only state the order AR needs is was it shipped or not.

[Thomas Oellrich]

I probably should have clarified that we're not using event sourcing. Does the recommendation to only check events apply here as well?

Speaking of DDD Exchange, I'm trying to convince my boss to send me and a colleague of mine over. Hope to see you there.

2011/5/26 Greg Young <gregor...@gmail.com>

[Greg Young]

I believe it is sold out at this point, might want to check that out
with SkillsMatter first.

[Thomas Oellrich]

That would be too bad. According to their web site one can still book.

Anyway, in a system that does not employ event sourcing but stores the actual state of the aggregate using Hibernate, would you guys still only check raised events in unit tests?

2011/5/26 Greg Young <gregor...@gmail.com>

[Greg Young]

yes.

[Jeff Doolittle]

I remember when I first started using CQRS and hearing these sorts of
questions and answers. I was initially skeptical but stuck with it
and have found that there are major payoffs to having totally
encapsulated aggregates where tests only exercise applied events.
There have been numerous times where I've wanted to refactor the
internal implementation of my aggregates. If I had tests that
referenced internal state, those tests would have to be modified as
well. It's a strong a hint that something is wrong with a design if
tests must be changed when the implementation details of a class
change. Refactoring can only be called refactoring if the *same
tests* can be used to exercise *different implementations* of the
*same behavior*.

Holub goes into great detail on the benefits of encapsulation -
http://www.holub.com/goodies/patterns/

--Jeff

On May 26, 1:20 pm, Greg Young <gregoryyou...@gmail.com> wrote:
> yes.
>
>
>
>
>
>
>
>
>
> On Thu, May 26, 2011 at 3:45 PM, Thomas Oellrich <toellr...@gmail.com> wrote:
> > That would be too bad. According to their web site one can still book.
> > Anyway, in a system that does not employ event sourcing but stores the
> > actual state of the aggregate using Hibernate, would you guys still only
> > check raised events in unit tests?
>

> > 2011/5/26 Greg Young <gregoryyou...@gmail.com>

>
> >> I believe it is sold out at this point, might want to check that out
> >> with SkillsMatter first.
>

> >> On Thu, May 26, 2011 at 3:23 PM, Thomas Oellrich <toellr...@gmail.com>

> >> wrote:
> >> > I probably should have clarified that we're not using event sourcing.
> >> > Does
> >> > the recommendation to only check events apply here as well?
> >> > Speaking of DDD Exchange, I'm trying to convince my boss to send me and
> >> > a
> >> > colleague of mine over. Hope to see you there.
>

> >> > 2011/5/26 Greg Young <gregoryyou...@gmail.com>

>
> >> >> Nope. You don't need to and binding your test to the internal state
> >> >> makes for brittle tests.
>
> >> >> I am doing my talk at DDD Exchange on these testing styles.
>

> >> >> On Thu, May 26, 2011 at 3:08 PM, Thomas Oellrich <toellr...@gmail.com>

> >> >> wrote:
> >> >> > Interesting. So you wouldn't actually check that the state of the
> >> >> > aggregate
> >> >> > has changed?
>

> >> >> > 2011/5/26 Angel Java Lopez <ajlopez2...@gmail.com>

>
> >> >> >> My first, quick and only aswer ;-)
>
> >> >> >> Unit Tests check the events raised.
>
> >> >> >> Angel "Java" Lopez
> >> >> >>http://www.ajlopez.com
> >> >> >>http://twitter.com/ajlopez
>
> >> >> >> On Thu, May 26, 2011 at 3:44 PM, Thomas Oellrich

> >> >> >> <toellr...@gmail.com>

[JoergEg]

See this video of the DDD Exchange which Greg mentioned:
http://skillsmatter.com/podcast/design-architecture/talk-from-greg-young

On 27 Mai, 17:39, Jeff Doolittle <jeffdoolit...@gmail.com> wrote:
> I remember when I first started using CQRS and hearing these sorts of
> questions and answers.  I was initially skeptical but stuck with it
> and have found that there are major payoffs to having totally
> encapsulated aggregates where tests only exercise applied events.
> There have been numerous times where I've wanted to refactor the
> internal implementation of my aggregates.  If I had tests that
> referenced internal state, those tests would have to be modified as
> well.  It's a strong a hint that something is wrong with a design if
> tests must be changed when the implementation details of a class
> change.  Refactoring can only be called refactoring if the *same
> tests* can be used to exercise *different implementations* of the
> *same behavior*.
>

> Holub goes into great detail on the benefits of encapsulation -http://www.holub.com/goodies/patterns/

> > de votre attention- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -