-
Notifications
You must be signed in to change notification settings - Fork 102
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
base: master
Are you sure you want to change the base?
Conversation
…Unit5, MyFaces' test framework and a reusable JUnit extension with the JSF mock container
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). |
Hi Stephan,
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:
|
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! |
Hello Stephan, nice ideas there, thanks for sharing. Please give me some time to think about it ... 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, |
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. |
there is no reason, just nobody did it; freel free to start a discussion on the MF mailing and work on it :D |
Progress is a bit slow at the moment, but I managed to build component trees from facelet files with 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 |
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. :) |
No description provided.