Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve AggregateTextFixture #67

Closed
sandjelkovic opened this issue Oct 9, 2020 · 6 comments · Fixed by #73
Closed

Improve AggregateTextFixture #67

sandjelkovic opened this issue Oct 9, 2020 · 6 comments · Fixed by #73

Comments

@sandjelkovic
Copy link
Member

Scenario

  • extension-kotlin version: 0.1.0
  • Axon Framework version: 4.4.x
  • Description of your use case: (detailed description or executable reproducer, e.g. GitHub repo)

Current Behaviour

  1. AggregateTestFixture currently requires a Class<T> aggregateType to be created.
  2. The method named when of AggregateTestFixture is used to set up the test, which forces Kotlin users to escape the method name since when is a keyword in Kotlin

Wanted Behaviour

  1. instead of passing Java's class object to AggregateTestFixture, a factory method with a reified generic parameter can be used instead. That would allow for a syntax like zaggregateTestFixture()instead ofAggregateTestFixture(GiftCard.javaClass)`
  2. An extension method on AggregateTestFixture which will alias/delegate to when, but will be called something else that is not a keyword. One option could be whenever, but anything else that make sense will do.
  3. This will require a new test module of the extension, to allow extension users to use the module only for testing.

Possible Workarounds

@jangalinski
Copy link
Collaborator

Not solving this, but interesting for testing with kotlin : https://github.com/holixon/axon-addons/tree/master/axon-jgiven

@zambrovski
Copy link
Collaborator

Since axon-test must be a separate module (because of the deps and different scope as the extension itself), do you think is it worth to create this inside of the extension?

A second question is -> what kind of test frameworks we want to support there? As @jangalinski pointed out, we provide a nice integration with JGiven, which can become "the standard" way of testing... And of course there are many Kotlin-test framework out there...

What do you think?

@sandjelkovic
Copy link
Member Author

Since axon-test must be a separate module (because of the deps and different scope as the extension itself), do you think is it worth to create this inside of the extension?

That is what I had in mind, and to mirror how axon-test can be included separately. There also may be other improvements that go inside this module such as saga fixtures, other testing enhancements or maybe even a DSL if something like that makes sense.

A second question is -> what kind of test frameworks we want to support there? As @jangalinski pointed out, we provide a nice integration with JGiven, which can become "the standard" way of testing... And of course there are many Kotlin-test framework out there...

In the module that enhances the Axon Framework's axon-test I'd keep it simple and try to stay neutral and extensible as much as possible, but I agree that something with other test frameworks can be good to have. As you said, there are a lot of frameworks and way to test in Kotlin world, and picking just one might not be the right move. Pulling them all as part of one module is also tricky as not everyone wants JGiven, Spek etc.

It might make sense to pull these out in separate modules, depending on the size and dependencies of course. What do you think @zambrovski @smcvb ?

@smcvb
Copy link
Member

smcvb commented Oct 19, 2020

With my, compared to you guys, limited Kotlin experience, I'd find it hard to gauge which of those testing frameworks would be the go-to solution. Aka, the one which "Axon Kotlin Extension" users would benefit the most from. At least I'd argue putting all options in a single module wouldn't be the ideal solution, so a segregating sounds reasonable to me (indeed depending on the size, and amount of work I'd say).

In the end I think it would not be to wrong to be slightly biased to "the best"/"most used" testing framework for Kotlin out there. If that's the bandwagon for Kotlin testing, then I wouldn't see why that shouldn't be this extensions testing-angle too. But as stated, I'd be hard pressed to tell you which that is. Trusting on your guys input on the matter.

@zambrovski
Copy link
Collaborator

zambrovski commented Oct 19, 2020

Ok, then I would suggest a "extension-kotlin-test" module fixing the issues with reified classes and the when keyword (so essentially one file with that small improvement).

Additional test modules should then not be a part of the extension but can be just separate libraries, like Axon-Jgiven is...

@zambrovski
Copy link
Collaborator

I just provide an implementation for it including the AggregateTestFixture and SagaTestFixture extensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants