TheCoder4eu / BootsFaces-OSP

BootsFaces - Open Source Project
Apache License 2.0
247 stars 102 forks source link

Unit tests for components and renderers #1185

Open flange-ipb opened 2 years ago

stephanrauh commented 2 years ago

Thanks for allowing us to glimpse "into the workshop"!

I like your approach using the *.txt files. It reminds me of the snapshot test of Jest (see https://jestjs.io/docs/snapshot-testing).

flange-ipb commented 2 years ago

Hi Stephan,

It reminds me of the snapshot test of Jest (see https://jestjs.io/docs/snapshot-testing).

Thanks for bringing this to my attention! Writing those txt files is just a dumb, but exhausting task, which requires automation. Searching for "java snapshot testing" already brings up promising projects, which can increase productivity.

A few words on the capabilities of the JSF mock container:

stephanrauh commented 2 years ago

I've sent you an invitation to the BootsFacesNext project. I'm afraid the project is dead, unless someone is ready to dedicate like 200 person days of work to it. Nonetheless, I think we had some innovative ideas concerning tests. Basically, the idea was to jot down the JSF source code as a file, like so (https://github.com/stephanrauh/BootsFacesNext/tree/master/lib/src/test/resources/alert):

<b:alert id="myId" title="giant alert" severity="danger" styleClass="giant"></b:alert>

and to write a second file containing the expected HTML file, like so:

<div id="myId" class="alert alert-danger giant" role="alert"><h4 class="alert-heading"></h4></div>

This is a very simple example, but I believe it's a simple and elegant way to create a feature-complete test suite.

As far as I remember, here's the test engine: https://github.com/stephanrauh/BootsFacesNext/tree/master/lib/src/test/java/net/bootsfaces/component. Just a few hundred lines of code.

Maybe that helps!

flange-ipb commented 2 years ago

Hello Stephan,

nice ideas there, thanks for sharing. Please give me some time to think about it ... I just had a déjà vu seeing LogStrings.properties in the project, because I also had to cope with it while writing component tests. ;D

One the other hand, rendering facelet files is easy in integration/E2E tests, where the application server takes care for it. Then you just assert on what the browser receives. Selenide seems to be capable of returning HTML of an element. I don't see anything like that in Selenium's WebElement at the moment.

Best regards, Frank

flange-ipb commented 2 years ago

Interestingly, there are a few tests for myfaces-impl that build component trees from facelet files (e.g. a test for c:forEach with forEach1.xhtml here). Unfortunately, most of the test infrastructure resides in the test directory of myfaces-impl and not in myfaces-test, which makes it not reusable - and I'm not willing to clone these classes here. Others already requested to move this infrastructure to myfaces-test (MYFACESTEST-59, MYFACESTEST-62), most probably for the same reason. @tandraschko: Any chance to achieve this in myfaces?

tandraschko commented 2 years ago

there is no reason, just nobody did it; freel free to start a discussion on the MF mailing and work on it :D

flange-ipb commented 2 years ago

Progress is a bit slow at the moment, but I managed to build component trees from facelet files with FaceletTestCase from MyFaces - there is no need to reinvent the wheel anymore :D. Fortunately, the MyFaces project pushes their test classes to the Maven repo! (And I noticed that right before starting to move this class and its dependencies to myfaces-test ...) I'm happy with this situation.

Managing two resource files for each test feels clumsy. I will investigate what snapshot testing can offer.

Note: I had to switch to JUnit4, because AbstractJsfConfigurableMockTestCase (the class, which FaceletTestCase inherits from) uses JUnit4 annotations, which don't play well with JUnit5 tests. org.junit.vintage:junit-vintage-engine provides backwards compatibility.

stephanrauh commented 2 years ago

As far as I can see, your progress is a lot faster than everything we managed to do!

Maybe you should allow us to merge your pull request when you think you've made decent progress. The point being you don't have to wait until you've covered every corner-case. Because that's a good recipe to keep the PR open forever. :)