Our project is in rapid development and we would like to test whether XML layouts are compatible with entities - using unit testing. I already did setup a test using CubaClientTestCase, but using @Mocked WindowManager does not actually do much so the test passes, even when it actually halts on similar error:
GuiDevelopmentException: Property 'test' is not found in entity 'project$Order'
Frame ID: project$Order..edit
XML descriptor: com/company/sample/web/order/order-edit.xml
The error is thrown correctly - in a fieldGroup, a part of order-edit.xml, I made a reference to not existing field of Order - test.
The test is here:
@RunWith(JMockit.class)
public class OrderEditTest extends CubaClientTestCase {
@Mocked
WindowConfig windowConfig;
@Mocked
WindowManager windowManager;
@Before
public void setUp() throws Exception {
addEntityPackage("com.company.sample.entity");
setupInfrastructure();
}
@Test
public void test() throws Exception {
Order item = new Order();
WindowInfo editorScreen = windowConfig.getEditorScreen(item);
windowManager.openEditor(editorScreen, item, WindowManager.OpenType.THIS_TAB);
}
}
Is there an example how to write a similar kind of test? I haven’t been very successful trying to find it. Thank you!
this is an interesting topic. I don’t really have an answer to this, because i didn’t used CubaClientTestCase much yet. You can start looking around by searching github for extends CubaClientTestCase. There is a similar thing for what you described in the XmlInheritanceTest.java which deals with the XML resources.
From my personal view this would be an integration test. The question generally is, since you called it “unit test XML layout” - what can be tested of the XML layout?
I think there are different scenarios:
reason about the created XML with its tags and properties (like is the TabSheet really with=100% etc)
not throwing exceptions like the one you described for missing fields in an editor
For the first one, as i said i don’t really have an answer (perhaps other people do).
For the latter i would assume that it should be possible but i’m not really sure if this is up to the app developer to do? When you look at the IDEA plugin, it will basically do exactly what you want: It marks attributes as red if there is no property path from the described entity.
So just thinking out loudly here, it might be possible for the platform team, since this logic is already implemented in the IDEA plugin, to create something that searches through all screens and look for invalid property path (either in fieldGroups or in tables). Basically it might be the same as detecting the problem at runtime and thworing a GuiDevelopmentException but instead let the generic logic be part of the gradle check task. Perhaps anyone with more knowlegde can elaborate on that.
Of course you have the opportunity to create a functional UI test in order to check for something like this, but i assume you intentionally tried to make it a unit test, right?
At the moment we don’t have such an infrastructure for tests that can enable you to check all your XML files. The only way to do this now is to create mocks for all the app level classes: WindowManager, App, AppUI and so on, but this process is too complicated to be widely used.
In fact, errors related with XML are not so often occur and could be checked in development time using IDE inspections and XSD schema. I’d recommend you to write tests for UI (using Selenium / Selenide) because it could give you much more confidence in your UI logic. For example, in our internal test project we have created generic UI test that opens all the windows from a menu and tries to open Create / Edit windows from browser and then checks if there are errors on browser side and in a server log. You can create such an integration test using Selenium and cuba.testMode property.
thank you all for your suggestions. I resolved this issue by extending ClientTestCase with many more @Mocked and @Tested services, but it is actually working - as per Mario’s suggestion I use this test to test all editor screens at once. No more “unresolved reference in XML layout” regression after changing my model. It was a nice excursion into the internals of Cuba J.