Java EE, Testing, Fast Turnaround
As part of the RichFaces 5 effort, we have undergone a huge refactoring of the RichFaces project structure . Why? Over time we have identified requirements which the project build cannot meet because the build at the time was not ready to support them...
When an issue is discovered in an real application, it needs to be reproduced by the dev team in a sandbox environment. It really helps to have this reproducer in the form of an automated test that should work on a given sample code, but that is failing due to the underlying issue...
This post is a wrap-up for the Testing JSF and RichFaces with Arquillian series which I started with: As we announced earlier, we are undergoing several changes in our approach to how RichFaces is tested. We already have an extensive functional test suite authored by a top-notch RichFaces QE team, but this suite doesn’t allow us to react quickly on regressions introduced and so we usually find some of them during release testing...
Once you started developing some integration tests, you should also think about how and where to run them. The last part of this series is dedicated to running tests in continuous integration...
We have previously discussed which technologies to use and how to improve the test development turnaround when we want to test JSF with Arquillian. However developing tests using the right tools used the right way isn’t the last stop in a development cycle...
In a previous post we have discussed what technologies we use for testing JSF and RichFaces in particular. The tools we use focus on testing complex business applications with rich user interfaces...
As we announced earlier, we are undergoing several changes in our approach to how RichFaces is tested. We already have an extensive functional test suite authored by a top-notch RichFaces QE team, but this suite doesn’t allow us to react quickly on regressions introduced and so we usually find some of them during release testing...
In RichFaces 4.3 we build upon a great work from Bernard Labno who prototyped the <rich:placeholder /> component and shared it in the RichFaces Sandbox. This component gives you an ability similar to the HTML5’s placeholder – it pre-fills form inputs with text, which serves as a hint for users of what data is a particular input expects...
The <rich:focus /> component allows you to focus on a form input once the user requests the JSF page update (either via a full-page load or an AJAX partial update). The <rich:focus /> component will make sure that the focused component is the best choice for the user based on following criteria: validation results tabindex settings position in the page which component was selected prior to the request Contributed by Community The <rich:focus /> is another sample of a RichFaces Community contribution – the component was initially proposed and implemented by Bernard Labno and he contributed it to the RichFaces Sandbox...
To whom of us using RichFaces CDK and being unsatisfied with a build time, our day just came! CDK got an incremental build feature, which caches information collected during a Library compilation and store it on a hard drive...
