We will enhance our domain model and allow users to register stock items for products.
Ensure Stock Items can be created during Product creation.
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
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
@TenantId
Let’s make our tests run as a particular tenant to mirror the actual user scenario.
Let’s enhance our domain model and add a central piece to the table: the rental order
This video is about adding validation tests for the new domain model of rental orders
Let’s create a custom validation for a rental order: a valid rental period
The @InstanceName annotated method for the Order entity is going to be tested this time
Order::getInstanceName method@InstanceName methods works as expected
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:
After the new test data creation approach, let’s use this for creating the order storage test
After having the domain model in place, let’s start with a very simple UI for the order
To improve user experience during order creation, let them search for customers directly in the screen
Dear Mario,
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?
Thank you for your time and expertise.
Best regards,
Hi,
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.
Cheers
Mario
After some small break (of almost two years 
), here the second part of the search customer in order creation functionality.
Let’s verify the search behavior to ensure the query definition is working as expected
Let’s give our users a little more context when creating an order. Show Customer details after selection
Let’s verify the search behavior to ensure the query definition is working as expected
The conditional UI logic from #34 should be tested. This is what we are doing in this video.
Component::isVisible vs. Component::isVisibleRecursive
When business requirements change, so does the data model. Let’s move the rental period from the Order Line entity to the Order entity to simplify usage. For that we in this video:
When business requirements change, so does the data model. Let’s move the rental period from the Order Line entity to the Order entity to simplify usage. For that we will, in this video: