[RFC] Possible flaw in projector scenario testing logic

[broadway]

[RFC] Possible flaw in projector scenario testing logic

[wjzijderveld]

A big difference in how we handle this, is that we always use an aggreate root id for our read model.
So in you example, the basketId would be returned by getId().

I think that would work for a lot of cases, but maybe you have a use case where that wouldn't work?

[mbadolato]

@wjzijderveld Yep that could work in situations, but not in this particular example (the last paragraph in my post).

Again, this is a contrived example and based off an example Mathias used in a presentation (I was doing his presentation examples using Broadway so that I could show someone a concrete example of an implementation, and have the presentation for them to follow along with as well), but I could see examples of where that could fail in a real world example.

In this example above, it's just dropping in basketId, productId, and productName, which could be the exact same for multiple rows in the read model. That basketId would be required for multiple rows (some which have the same productId and productName in it) so the uniqueness doesn't really come into play there and a separate id is needed. Otherwise, the InMemory repository would only store one object with the basket/product/name combo (again, assuming no quantity or other distinguishing attribute in this case).

When I was first building the example, the ProductWasAdded and results were actually ok. This was because $id was null, the save() function just used null as the id, and the repository was still able to store and return the object to me, which matched my test because I was also constructing the object to compare against and it had a null id.

The problem showed itself when I tried to execute the exact same event in when() clauses more than once. Because of the id situation, the id was null and the repo overwrote the first object with the second upon storage, so the then() failed to match what I expected (two objects, same attributes).

It was when I went to make each read model object generate a unique id to mitigate that situation that I realized I couldn't then duplicate the object in my test because I wouldn't know the id.

[wjzijderveld]

In my opinion you shouldn't generate the ID from inside the read model, and exactly for this reason, that it gets a lot harder to test.

In your example I would still inject an unique id for that item. To me it already seems weird that a read model isn't unique on itself. In this case I would name the read model something like BasketItem and inject an extra basketItemId that would become the id that gets returned by getId.