Upcast, Kotlin and Unit Test

[Mike]

Hello guys,

I'm using Kotlin so non-null safety is something that I want to keep. 

So I really need a good way to write a Unit Test for Upcast because kotlin is very stern about non-null.

How are you guys writing your tests for Upcast?

[Steven van Beelen]

Hi Mike,

I typically have a unit tests for an upcasters which has a serialized version of the old event and of the new event.

Then, I push the old event through the upcasters I've created, serialize the result of the upcasted event and match it to the serialized version of the new event.

That, in short, is what I'd suggest to do to testing if you're upcasters does what you expect it too.

Ow, and one additionally note, I'd highly recommend to add the revision number to the upcasting class and it's test class, as chances are high that you'll introduce subsequent upcasters for any given event.

Thus stating the rev. number on your upcaster keeps them apart easily.

That's my 2 cents.

Cheers,

Steven

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Armando Fernández]

Hi Steven, 

I just run into this post while looking for a way to unit test my upcasters. How exactly are you "pushing the old event through the upcasters" in your unit test?

I'm looking into it now, so I may find a way to do it myself today, but I thought I'd ask here as well. 

Thanks,
Armando.

To unsubscribe from this group and stop receiving emails from it, send an email to axonfr...@googlegroups.com.

[Steven van Beelen]

Hi Armando,

In the example I related to in my reply here, the approach taken was to store the serialized format of the events as test resources.

So more specifically, we had `.json` files (as we serialized to JSON) containing the structure of the event at a given revision number.

The rest of the file name would resemble the payload type of the event (by default it's class name), appended with the revision number as well.

That way we could introduce an abstract UpcasterTest, which required developers to provide the event name and event revision.

Based on the result of both, the abstract UpcasterTest would expect a file resembling the aforementioned naming scheme and load the file.

The contents of it would thus be the serialized format of the event, exactly what we needed to test the upcaster with.

Hope this clarified some things Armando!

Cheers,

Steven

To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/axonframework/1ca1a60b-03fb-4515-a2c8-fe24bcf4a309%40googlegroups.com.