Monday, November 5, 2007

JSFUnit and Grey-box testing

An anonymous viewer posted a question about the nature of JSFUnit. I was going to reply directly to the comment, but I felt that the answer needed its own top-level post since it is so fundamental to the nature of JSFUnit.

Anonymous asks,
Why do you want to implement another testing framework? Why do you not consider WebTest ?
The answer is that frameworks like WebTest, HttpUnit, HTMLUnit, etc. only test the client side. These are pure black-box frameworks for web apps.

With JSFUnit, you get both client side and server side testing in one test. Some call this grey-box testing.

Plus, the JSFUnit API is written specifically for ease of testing everything you would want to know about a JSF application.

For instance, with JSFUnit I can not only submit data on a form, I can also make sure that managed beans were properly updated (using EL expressions).

I can make sure that my component tree on the server side is correct using the actual server-side objects created by JSF. Checking the server-side component tree has three distinct advantages that you don't get with just checking the HTML:
  1. It's much easier as I can make simple JSF API calls instead of checking raw text or the contents of the client-side DOM.
  2. I don't have to rewrite my test when the HTML changes.
  3. I can validate components where rendered=false. In this case, the component is not rendered on the client side, but still has state on the server side.
With access to the FacesContext, I can test navigation from the server side with a simple check of the viewID. If you are only testing the client side, you have to infer the viewID and that inference may become wrong as the application evolves. Again, the test breaks simply because you changed the HTML, not because you changed the application logic.

I could go on and on about server side testing. There is a lot more to be validated such as database state, security state, and even memory usage.

If I want to do the client side (black box) testing, JSFUnit gives full access to the HttpUnit API and the client-side DOM. So that is covered as well. And again, I can even do both black box and white box testing in the same test if I want.

Lastly, JSFUnit includes static analysis tests that do validation of your configuration beyond what JSF itself provides. This lets you know about problems specific to JSF that you can catch long before they show up in some obscure use case at run-time.

Good question Anonymous. So long, and thanks for all the fish,



Kito D. Mann said...

Stan, I think you're right about how useful JSFUnit is, and how it's different than WebTest or Selenium. However, since it doesn't fully support Ajax-enabled components other than those from JBoss, I don't think it's the best choice for black box testing if you're using another component suite.

Stan Silvert said...

Hi Kito,

I totally agree with you. For now, other libraries aren't fully supported because of the "proprietary" ways components construct AJAX requests.

Rest assured, we do plan to support other component libraries as soon as possible though.

Beta 1 will include support for RichFaces and Ajax4jsf. The next step will be to create a common framework that makes it easy to add more and more AJAX components from other vendors. I'm already talking with someone who is interested in helping with Trinidad.


Stan Silvert said...
This comment has been removed by the author.
Anna said...

Great and Useful Article.

JSF Online Training

JSF Training

JSF Interview Questions

JSF Tutorials