Discussion: going well with tests

[flange-ipb]

Hello everyone! It's nice to see that my most favorite component library is going towards support for Jakarta Faces.

I'd like to suggest, discuss and contribute a few improvements to testing in this project. At the moment I see almost no tests at all and I'm quite impressed how far BootsFaces evolved without them.

(1) Unit tests of custom components Mocking of JSF's internal classes like FacesContext for tests is painful, but this is required for testing components. Fortunately, the good people over at MyFaces have done this already. Creating a test environment with MockedJsfTestContainer is pretty easy. When adding a specific implementation of ResponseWriter (e.g. HtmlResponseWriterImpl from MyFaces or Mojarra's HtmlResponseWriter) it is even possible to spy on what components encode in their encodeXXX() methods.

(2) Integration tests (aka automated browser tests) (Yes, I've seen BootsFaces-Tests, but this has never caught momentum.)

Let's look at PrimeFaces' integration tests:

• The web project with the test pages is deployed in an embedded Tomcat, which can have different JSF implementations (provided via different maven profiles). Until a few months ago they have used TomEE-embedded with the same JSF implementation exchange strategy. Tomcat/TomEE are started before any test execution via a JUnit5 Extension (see BootstrapExtension and TomcatDeploymentAdapter or PrimeFacesSeleniumTomEEAdapter).
• For browser automation they use Selenium with a lot of custom improvements. Especially AJAX calls can be very painful with plain Selenium making tests flaky. You'll see at lot of PrimeSelenium.guardAjax() calls in their tests. On the other hand, BootsFaces-Tests already used Arquillian Graphene with its famous guardAjax() method.
• Selenium needs a browser-specific (and browser-version-specific) webdriver implementation. PrimeFaces downloads that automatically with webdrivermanager. Unfortunately, it downloaded the wrong versions on my computer, because my Debian stable uses old browser versions like Firefox ESR. I cannot execute their integration tests! Do you see the problem? The test execution relies on browsers installed on my system and this adds to flakiness.

My ideas for improvements:

• Deploy the web project in an application server (TomEE, Glassfish, etc.) inside a Docker container. The advantage of TomEE is that it offers MyFaces (TomEE WebProfile or Plus) or Mojarra (TomEE Plume) as JSF implementation. If necessary, the docker container can be controlled via Testcontainers with a few lines of Java code.
• Plain Selenium is just horrible! I propose to use Selenide, which delivers stable browser automation and test assertions, even with AJAX calls. Forget about guardAjax(), it just clutters up the test code and slows down test execution.
• Run the browser inside a Docker environment. I recently started using Selenoid, which simply downloads the latest browser versions. Selenium/Selenide instances just use the RemoteWebDriver class to connect to it. Webdriver containers of Testcontainers might also be something to look into.

What do you think?

Best, Frank

[stephanrauh]

Hi Frank,

first of all, thank you so much for your valuable and well-thought suggestions! Plus, thanks a lot for your kind words!

Bear with me dedicating the next paragraph to philosophic thoughts. I'm coming back to tech the paragraph after that.

IMHO, test automation is a little over-rated. It's great, but as you said, we've managed to be successful without automated tests. Omitting test automation is not the same as omitting tests. But that's just my personal opinion, fueled by years of experience in projects that were way to dynamic to support test automation. It goes without saying that a framework like BootsFaces should not be that dynamic. It needs to be stable. So there's nothing wrong with test automation. Nonetheless, allow me some shameless self-advertisement. I've written a series of articles covering my thoughts about testing: https://www.beyondjava.net/how-to-test-an-application (plus the two consecutive articles).

There's that. We can easily agree it'd be a good idea to add a decent test coverage to BootsFaces. The real problem is we've run out of active contributors. At the moment, there's little progress, so there's little need for tests. Sigh!

I'm not ready to put up with this situation. I'd love to win contributors. Even in the age of Angular, Vue.js, and React.js, BootsFaces enjoys a stable - and even growing - number of users. At the moment, that's roughly 4000 downloads per month. I can only guess how that translates to the number of active developers, but I suppose it's a five-digit number. That's at least 10.000 signs of trust and 10.000 reasons to say "thank you!".

I'd like to encourage you, Frank, and everybody who's reading this, to contribute tests to BootsFaces. I recommend starting simple. We've tried to add tests to BootsFaces several times, and each and every time our goals turned out to be too ambitious. I guess it's better to add some simple unit tests at crucial algorithms. Tests that are easy to implement but still add extra value.

However, what I'd really like to see is bug fixes and new features. :)

As for your discussion on Selenium: thanks a lot for that. Selenide and Selenoid are new to me, I need to dig into that. All I can say is my experience with Selenium is anticlimactic, so I'd like to learn about alternatives. I'm more familiar with the Angular world. Is there a counterpart to Jest, Phantom.js, or Cypress in the Java world?

Best regards, Stephan

[stephanrauh]

I'm afraid the development of BootsFaces has slowed down so badly we won't ever implement tests. Let's close the ticket.