Issue #22 - Remove flakiness from UI integration tests
After finding out about the problem with the UI integration tests in video #21, lets dig deeper into the problem and resolve the root cause of the flaky tests
see tests running in isolation, but not in the whole suite
debug tests to find problem of incorrect entity comparison
find out that multiple screens are still open from other tests
reason about shared state of “opened screens”
fix by clearing up all screens at the beginning of each test case
In order to offer the application to multiple clients, let’s enhance the rent-your-stuff application with multi tenancy in order to create a real SaaS solution
add multi tenancy add on
enhance entities with @TenantId
adjust user management UI to support multi tenancy
Issue #29 - Create rental order - Part 5 - Test data creation
In order to create a storage test for the order, let’s improve our test data creation approach a little bit. This video will guide you through this process:
add two depenencies: Lombok & MapStruct to your Jmix application
use Lombok’s @Builder annotation for a data class that only contains the business attributes
use MapStruct for mapping the data class to the JPA entity using the Jmix DataManager
create pre-build product data with the Products test bean
refactor the product storage test to use the new approach
I hope this message finds you well. I wanted to express my gratitude for your informative video series. I’ve learned a lot from it.
Regarding UI testing, I’ve been researching the most suitable approach for Jmix 2.0.1 and came across the “Masquerade” library for UI testing. I’d appreciate your guidance on whether I should use it. If you recommend it, could you provide some instructions or tips to ensure consistency with the content in your videos?
From my experience browser based e2e testing is comparably expensive and slow compared to other alternatives. Therefore I normally apply the pattern: if a specific functionality can be tested on a different level, I tend to do it there. In Jmix/Vaadin land this is UI integration tests. With those you are not able to test every situation (like client based in interactions, for example the date picker), but almost all logic based situations that you create through code.
But if you really need browser based testing and can live with the downsides it brings, then Masquerade seems to be a valid choice, as it knows all the Jmix specifics.
But I think it is not compatible with Vaadin 24 / Jmix 2.x yet.