Split engine and assertions into separate modules #166
Conversation
remcowesterhoud
force-pushed
the
90-split-modules
branch
from
9b48904 to
7c0b3ee
Compare
There was a problem hiding this comment.
So... this one is a little difficult to review. You say it's a first step. Maybe it's just different from the first step I would have made. Or maybe the first step is too small for me.
Let me tell you what I mean, and then maybe you can tell me what your next steps are going to be.
I guess my first step would have been to extract (and rename) InMemoryEngine and RecordStreamSource into their own module. This module will only have these two interfaces, most likely. And it's artifact name is probably something ending in -api.
Then both *-test-engine and *-process-test could depend on these shared interfaces to a) control the engine and b) fetch the records from it.
I am also still dwelling on the idea that I would at some point in the future like to see a module which has just the assertions, without the extension. I guess it is not strictly necessary since we decided we don't wont multi-version extension, but instead always use the containerized form.
However, having the assertions cleanly without the extension would allow us to use them inside Zeebe to rewrite some of the tests which are based on records. Then we would just need to rewrite the logic to provide the records.
But if the extension stay part of it, then it will pull in additional dependencies to test containers and such things. But maybe I am getting ahead of myself.
Lastly, Nicolas was lately talking about using Flatten POM in Zeebe. I must admit I haven't fully understood how it works. But from what I gathered I think it could be a game changer to deal with transient dependencies. So I would encourage you to talk to Nicolas about it and employ it here, whenever you can.
|
Thanks for reviewing. I agree that it makes sense to move the interfaces to a separate module as well. The whole communication between the assertions and the testcontainer is still a bit unclear to me. Maybe we can have a chat about that soon? I hear you about the extension. I wanted to keep this change "small" and figured we could do this in the future. But now that I think about it again, moving the extension would be a breaking change so it'd be better to do this right away. I saw the post about flattening pom files. I want to look into it properly first, but from what I understood it's just a plugin. I'll create a new issue for it. I isn't part of the module split so I don't want to add it to this PR. |
|
Just had a look at it. I was wondering whether all tests need to be in QA. I would hope that some tests could just as well be in the module of the classes they are testing ( e.g. |
|
@pihme I don't agree on moving the I have also moved the |
|
I committed it to the wrong branch 🙈 It's pushed now. |
In order to support Java 8 a first step is to split the project into separate modules. This enables two things:
1. The test engine can be containerized. This allows us to run tests using testcontainers instead of needing a dependency on the engine.
2. The assertions can now be used stand-alone. This allows for reusing the assertions in different projects that don't require the engine, removing a lot of overhead.
The project has been split in 5 modules:
1. Api
- This module contains public interfaces. It should always be Java 8 compatible.
2. Assertions
- This module contains all the assertions. It should always be Java 8 compatible.
3. Engine
- This module contains the in memory engine. It is not bound to a specific Java version. The api and assertions module should never depend on this module.
4. Extension
- This module contains the annotation for your unit tests. As of now it depends on the engine and thus is not bound to a specific Java version. In the future this dependency will be removed making this module Java 8 compatible
5. QA
- This module contains our QA tests. These are the tests that span multiple modules. There is no reason to depend on this module. It is not bound to a specific Java version.
remcowesterhoud
force-pushed
the
90-split-modules
branch
from
bcc7cce to
c8429fb
Compare
Description
The first step to supporting Java 8 is isolating the engine from the assertions. With this change I have split the code into 2 separate modules, the engine module and the assertions module.
The engine module is responsible for everything that has to do with running the processes. It will house the
InMemoryEngineand theInMemoryDb. This module will be dependent on other Zeebe modules and will stay up to date with Java versions.The assertions module is responsible for verifying the process. It contains assertions and other methods to traverse the record stream in order to verify the process behaves as expected. It also contains the
ZeebeProcessTestannotation.This module should support Java 8. This means it cannot have any dependencies on Zeebe modules that will update to higher Java versions. For now it still has a dependency upon the engine module, but this will be removed once we can run the engine in a testcontainer.
Related issues
closes #90
Definition of Done
Not all items need to be done depending on the issue and the pull request.
Code changes:
Testing:
Documentation: