Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unit tests for components and renderers #1185

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

flange-ipb
Copy link

No description provided.

…Unit5, MyFaces' test framework and a reusable JUnit extension with the JSF mock container
@stephanrauh
Copy link
Collaborator

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
Copy link
Author

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:

  • It is possible to construct a component tree programmatically; UIViewRoot is also present via FacesContext's getViewRoot().
  • JSF's event engine can be used.
  • Rendering from facelet files does not work.

@stephanrauh
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Author

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
Copy link

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
Copy link
Author

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
Copy link
Collaborator

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. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants