Subscribe: Test, Test, JSF
Added By: Feedage Forager Feedage Grade B rated
Language: English
beta  fish stan  fish  jboss  jsf  jsfunit  long fish  long  new  release  server  side  support  test  testing  web 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Test, Test, JSF

Test, Test, JSF

This is a blog about testing and JSF. But mostly, it's about JSFUnit, the new JSF testing framework from JBoss.

Updated: 2016-07-23T13:14:48.236-04:00


Setting JSF ProjectStage with JNDI


One nice feature of JSF2 is the ProjectStage setting.  It lets the JSF implementation and the application developer optimize and customize behavior based on whether JSF is running in Development, Production, SystemTest, or UnitTest.  The usual way to tell JSF about which ProjectStage to use is through a context param in web.xml. javax.faces.PROJECT_STAGE DevelopmentBut you would rather not muck with web.xml for something like this.  It's much cleaner to define your ProjectStage based on what kind of server environment you are running.  In other words, wouldn't it be nice if JSF could know whether your server is running in Development, Test, Production, etc?  Then you wouldn't need to change your application at all.A little-known but handy feature of JSF2 is the ability to use JNDI to set the JSF ProjectStage.  Here is how you do that in JBoss AS7.First, add a resource reference in web.xml. jsf/ProjectStage java.lang.StringThen, create a jboss-web.xml file and place it beside web.xml in your WEB-INF directory. The file should bind the resource reference to JNDI like this: jsf/ProjectStage java.lang.String java:/env/jsf/ProjectStage Next, add the JNDI value to JBoss AS7 in the naming subsystem of your configuration file, such as standalone.xml:                                                      You can also add the JNDI value using CLI: /subsystem=naming/binding=java\:\/env\/jsf\/ProjectStage/:add(binding-type=simple,value=Development,class=java.lang.String)But I like to use CLI GUI for this because it automatically handles the escape characters: Now we are done, but you might also want to change the value of ProjectStage on your server. Again, you can do that in XML or you can use CLI: /subsystem=naming/binding=java\:\/env\/jsf\/ProjectStage/:write-attribute(name=value,value=UnitTest)[...]

Multi-JSF is here! Use any JSF in JBoss AS


Multi-JSF is a JBoss AS feature that I've wanted to implement for a very, very long time.  Basically, it allows you to use any JSF implementation as if it were the impl that ships with JBoss AS.  This works with almost any version of MyFaces or Mojarra.  You can even install multiple JSF implementations and tell each app which one to use.

Until now, if you wanted to use a different JSF version, you could hack AS7.  But this only worked for Mojarra implementations.  If you wanted to use MyFaces, you had to resort to bundling JSF with your web app and setting WAR_BUNDLES_JSF_IMPL in web.xml.

Both methods had potential integration problems if you wanted to use JEE5 features such as @EJB , or JEE6 features like CDI and bean validation.  What's worse is that if you wanted to use more than one JSF version you would end up bundling JSF with every WAR.

In short, it was messy and it didn't always work.  Plus, WAR_BUNDLES_JSF_IMPL isn't even officially supported.

Multi-JSF is now in the latest nightly build of 7.2.0-Alpha1.  You can get all the details on how to use it at

I hope you'll try it out and provide some feedback before AS7.2 goes final.

So long and thanks for all the fish,


JSFUnit 2.0.0.Beta 2 is Out


It's hard to believe that it has taken this long to get from Beta 1 to Beta 2. There were some good reasons for it. One is because we were waiting for Arquillian and JBoss AS7 to stabilize. The other reason is just because I haven't had as much time to work on JSFUnit as I did in the past. Most of my time has been taken up with AS7-related stuff.

However, I'm thrilled that the community has come to the rescue! In fact, the community gets almost all the credit for this release. First, there is Josè Freitas. Josè did most of the coding to get the us running with the latest Aqruillian and JBoss AS7. This included porting the CDI-based annotations to use Arquillian TestEnricher. Now, you no longer need CDI for the new annotations to work. That's a big help for containers that don't natively support CDI.

We got some further help from JBoss developers Aslak Knudsen and Andrew Lee Rubinger. Plus, there were lots of community members who stepped up to answer questions on the JSFUnit forum while I was less active. Wolfgang Knauf even went so far as to write a comprehensive tutorial on using JSFUnit Beta 2 with Eclipse.

So, what's new in the release?
You can click here for the official release notes.

In summary, we now fully support the latest version of Arquillian and added the long-awaited support for JBoss AS7. As mentioned above, the annotations no longer require CDI. And, we've moved the source code to GitHub. That should make it even easier for everyone to get involved.

Here are some helpful links to get you started:
Getting Started with JSFUnit 2.x
Getting Started Sample App
JSFUnit 2.x FAQ
JSFUnit 2.x Annotations

Hope you enjoy the release. We'll probably do one more beta soon. But with all the extra help, it shouldn't be long before JSFUnit 2 goes final.

So long and thanks for all the fish,


JSFUnit 2.0.0.Beta1 is Out


I'm very excited to announce the availability of JSFUnit 2.0.0.Beta1. The two biggest shortcomings of JSFUnit 1.x were always a lack of JUnit 4 support and relatively slow execution times compared with "mock object" solutions.

The reason we couldn't do anything about this up until now was because JSFUnit 1.x needed Cactus as the in-container test runner. Being in-container has tremendous advantages because you don't need the messy mock objects and you can run your tests against the real system. But Cactus is rather old and it only supported JUnit 3.

So now, JSFUnit 2.x takes advantage of the new in-container framework from JBoss called Arquillian. It not only supports JUnit 4, but you get TestNG support to boot. And depending on the container you choose, the speed can be really fast.

Here are the links you need to know about to get started:
Getting Started with JSFUnit 2.x
Getting Started Sample App
JSFUnit 2.x FAQ
JSFUnit 2.x Annotations

I want to thank those who have helped with this release. Thanks goes to Ole for his nifty new method to click a RichFaces panel bar item. Also thanks to Bernard Labno who has been working hard on some additional RichFaces support. His code hasn't been integrated yet but I'm confident that his work will solve some long-standing issues with ajax queues.

And last but not least, thanks to Aslak Knutsen and all his fellow contributors to the Arquillian project. You guys have been extremely helpful. I'm sure our two products will continue to complement each other and spread the gospel of in-container testing.

So long and thanks for all the fish,


JSF on JBoss AS6 Final


When I do blog here, it's usually about JSFUnit. But today it's time for me to blog about the other stuff I do at JBoss. Besides JSFUnit, I'm also responsible for JSF integration in the JBoss Application Server. With JBoss AS6 going final, I'd like to talk about some big improvements.A short history of JSF on JBoss ASJSF has been integrated into JBoss AS since version 4.0.3. Back then we were using MyFaces 1.1. All it really meant was that JSF would be on the classpath so you didn't need to bundle JSF with your WAR any more. The integration was so crude that you still had to declare the MyFaces context listener in your own web.xml.With JBoss AS4.2 and AS5, integration got tighter. We switched to Sun's JSF 1.2 implementation, now known as Mojarra. JSF 1.2 included support for JEE5 annotations on your managed beans such as @PostConstruct, @PreDestroy, and @Resource. It also included integration with JSP and EL. And, you no longer had to declare a listener in your own web.xml.Despite better integration and more features, some people got mad. You see, even though MyFaces and Mojarra comply with the same spec and pass the same TCK, they are not 100% compatible. So apps that ran fine on AS4.0.3 broke on AS4.2 and AS5. What's more, the reality is that JSF apps are not even fully compatible from version to version. Apps that run fine on Mojarra 1.2 might not run on Mojarra 2.0.And don't even get me started about JSF component libraries. Suffice it to say that compatibility between versions and implementations is even worse.JSF on AS6: Coming to grips with realityThe reality is that an application server needs to play nice with more than one JSF implementation. So with AS6, we ship with three versions of JSF. Mojarra 2.0 is there as the default implementation. Mojarra 1.2 is there to ease migration from AS5. And, MyFaces 2.0 is there for those who prefer MyFaces. To choose a different JSF, all you need to do is declare a single context param in your web.xml like this: org.jboss.jbossfaces.JSF_CONFIG_NAME Mojarra-1.2But it doesn't stop there. If you want to bundle JSF with your WAR like in Tomcat, that's fine. If you want to add a fourth JSF version to JBoss AS and make it the default, that's easy to do.You can even bundle a component library together with a particular JSF version and call that "MyPerfectJSFConfig". Then refer to the JSF Config in web.xml for all your apps that use that. No need to bundle RichFaces or IceFaces jars over and over with every WAR: org.jboss.jbossfaces.JSF_CONFIG_NAME MyPerfectJSFConfigThis is all really handy for testing your application against different JSF versions and implementations. Ever ask yourself if your Mojarra app would run faster (or without errors) on MyFaces? Now it's easy to find out. What if you have an old app that runs on JSF 1.2 but you also have a new app that runs on JSF 2.0? You don't have to worry that the upgrade to JSF 2.0 will break the old app. They can run side-by-side in the same JBoss AS instance without changes.If you want the details on how to do this stuff, take a look at the JSF on AS6 documentation.All this and moreI don't want to leave out the fact that all the JEE integration you expect will be there. If you are using JSF 1.2 you will get the EE5 features like annotations on your managed beans. If you are using JSF 2.0 you will also get EE6 features like Bean Validation.In summary, I'm really proud of the JSF integration in AS6. It took a lot of work to get this level of flexibility. And I can honestly say that every JSF integration complaint I heard in previous JBoss versions is now fixed and addressed. Onward now to JBoss AS7.So long, and thanks for all the fish,Stan[...]

JSFUnit 1.3.0.Final is Released


A Small Release with Big Consequences

JSFUnit 1.3.0 is out. There are only three interesting changes:
  • A new API call on RichFacesClient for Drag and Drop
  • Updates for compatibility with HtmlUnit 2.8
  • One JSFUnit bug fix
The Drag and Drop thing is nice. And HtmlUnit 2.8 fixes a LOT of the bugs from 2.7, several of which were reported by the JSFUnit community.

But the big story is the one tiny JSFUnit bug fix submitted by Aslak Knudsen. You see, that fix enables JSFUnit to integrate with Arquillian. If you are not familiar with Arquillian, this is a new JBoss project that handles deployment and test execution for in-container tests. It's an elegant, modern replacement for what we do now with Cactus and Cargo.

So going forward, you will be able to run your JSFUnit tests using either Arquillian or Cactus/Cargo. The advantages you will have with Arquillian are:
  • Full JUnit 4 support (yay! we can finally use the @Test annotation!)
  • TestNG 5 support (yay! if you prefer TestNG)
  • Resource injection into your test classes (stuff like @Inject or @EJB can go right into your test)
  • Testing for subsets of your WAR. For instance, if I only want to test two facelets and one managed bean it will package those into a small WAR, deploy it, and run the test. This is great for development because single tests will run much faster without creating the whole giant WAR.
The one disadvantage I can think of is that Cargo supports more containers. Arquillian currently supports JBoss AS, Glassfish, Jetty, and Tomcat. But I'm sure more are on the way.

So when can you try out the JSFUnit/Arquillian combo? Aslak already has a proof of concept. It looks like we may be ready to let it loose in just a few days. Stay tuned.

So long, and thanks for all the fish,


P.S. Note that some dependency versions have changed. Check out the getting started page for the complete list of jars you need to upgrade.

A Patent on JSFUnit


... or more precisely, I/we patented one of the key technologies JSFUnit uses. About the same time I was starting the JSFUnit project, Red Hat's lawyers announced a push to get us to file software patents. I did so reluctantly because I think that in the end, software patents are a game that only the lawyers can win. But Red Hat has a good strategy when it comes to patents that I think ultimately benefits everyone. Read below for more on that.

So it took over three years to get it done. You can view the patent here if you want the gory details.

What does the patent say?
Basically, it just says that we keep the FacesContext alive after the request is done. Without JSFUnit, the JSF Lifecycle would throw it away. That lets us do assertions on the state of the system after each JSF request. If you've been using JSFUnit then you probably know all about that. It's what makes JSFUnit unique among testing tools.

What does the patent mean for JSFUnit users?
Nothing. The software is still open source. We're not looking to make money off of the patent.

Why did Red Hat want to patent this in the first place? Doesn't this go against Red Hat's philosophy of openness and freedom?
Yes and no. Red Hat doesn't really like software patents either. But we see them as a necessary evil until some laws are changed. As I understand it, the Red Hat Patent Promise says that anyone can use our patents for free as long as you don't file a patent case against us.

So long and thanks for all the fish,


*Disclaimer: I'm not an attorney. The above is my own understanding of this stuff. I'm not even qualified to write this disclaimer.

JSFUnit 1.2 Goes Final


We just put out a new release of JSFUnit. This time besides bug fixes, we have few new features to talk about:
  • JSF Static Analysis Returns - A big thank-you goes to our newest committer, Alexander Jesse. He has updated some of the old JSF static analysis code and made it really easy to test your JSF configuration for common errors. Some of the old static analysis stuff is still there but his ConfigFilesTestSuite looks awesome. Click here to check out the documentation.
  • New API for working with RichTree components - Of all components, developers using JSFUnit seem to have the most difficulty with RichTree. That's understandable because it is a very complex component. In JSFUnit 1.2.0 the RichFacesClient has new methods for working with RichTree. You can read about that here.
  • Easier Configuration for Servlet 3.0 - If you are lucky enough to be using a Servlet 3.0 container such as JBoss AS6, you no longer need to change your web.xml. JSFUnit will add the needed servlets and filters at deploy time.
  • JSFUnit Console - This is one of the cooler new features, but it also requires Servlet 3.0. JSFUnit now provides a browser-based console for launching your tests. You don't have to do anything extra. You just need to deploy your app and type http://locahost/myjsfapp/jsfunit into the browser. You can read all about it here.
A note about upgrading. If you are upgrading from JSFUnit 1.1.0 you will need to upgrade some of your jars that you package with the WAR. They are:
  • htmlunit-2.7.jar
  • htmlunit-core-js-2.7.jar
  • nekohtml-1.9.14.jar
  • commons-codec-1.4.jar
Also, there have been a few bug fixes in HtmlUnit for RichFaces. So if you run into trouble you can find an HtmlUnit 2.8 snapshot from the latest build that contains the fixes.

As always, thanks to everyone who contributed to this release with patches and feedback.

So long and thanks for all the fish,


What's a WARlet ???


JSFSpy ProgressToday I uploaded a new snapshot of JSFSpy. BTW, I'm keeping the name JSFSpy. Even though I don't like it that much, it's short and to the point. Thanks to those who had other suggestions earlier this year. JSFSpy is super-easy to install. Just drop the JSFSpy core jar into your WEB-INF/lib and you are ready to go. Click here for details.What's a WARlet ???In short, a WARlet is a WAR plug-in. It provides one or more Facelet views via a WARlet container and some Servlet 3/JSF 2 magic. A WARlet is neatly packaged in its own jar. The jar contains any xhtml, css, images, and classes that it needs. This provides a module of UI and processing logic that you can add to your WAR with zero configuration.If you happened to catch my JSFSpy presentation at JSF Summit a couple of weeks ago, you saw a WARlet in action. I'll re-create that demo here. Notice the JSFSpy menu buttons at the top:I took JSFSpy and bundled the WARlet container along with it. Then I took my EL_Evaluator WARlet jar and dropped that into WEB-INF/lib. Redeploy and Viola!! Now an EL Evaluator button appears in my application on the far right.The button can launch the EL Evaluator functionality. Here is the EL Evaluator:So how does the button get added? JSFSpy doesn't know anything about EL Evaluator. It only knows that one or more WARlets might be present. So the button menu has this markup to display a launch button for any WARlets that happen to be there:So what this all means is that anyone in open-source land can create their own WARlet that plugs into JSFSpy. I'll be posting more about how to create a WARlet in the near future. If you just can't wait to write your own you can browse the JSFSpy source, example code, and WARlet container source.The only catch is that all this requires Servlet 3.0 and JSF 2.0. Nothing wrong with the bleeding edge, eh?So long, thanks for all the fish, and have a great holiday!Stan[...]

JSFUnit Podcast on JSFCentral


Kito Mann just posted a podcast of yours truly on JSFCentral. It was recorded at a JSF Conference almost a year ago when JSFUnit was still in beta. But you might still find it interesting:

I'll be speaking at the conference again this year in Orlando. Hope to see you there.

So long and thanks for all the fish,


JSFUnit 1.1.0.GA is released


The latest JSFUnit release is now out. This is primarily a bug-fix release, with several of these fixes related to Seam. The only significant new feature is the ability to parameterize your tests.

We now recommend using HtmlUnit 2.5 instead of 2.4. Also, everything is updated to the latest beta version of JSF 2. So now you can use JSFUnit with JSF 1.1, JSF 1.2, and JSF 2.0 Beta 2.

As for JSF Spy (JSF Eye?), this is not ready for a release. It will probably become its own separate project soon.

So long, and thanks for all the fish,


Help Me Name My Baby


I've got a new baby and I don't know what to name it. It's a new JSF debug/trace/performance tool. If you've ever seen the Facelets or Seam debug page then you've got an idea of what it is. However, this tool goes beyond those to take "state snaps" before and after each phase. And, it keeps all the info from every request and every session, even expired sessions. Pre-alpha documentation and download is here. So now you can debug those nasty AJAX components that do four or five JSF requests with every mouse click. You see all the HttpServletRequest data like params, headers, and cookies. And, you can look at the performance data for each request and each phase.For now, we store this info in memory for you to peruse at your leisure. Later, I'll probably look at other options like saving to a database. That way, it might be a fit tool for production auditing.So right now you are either thinking this is really cool or really nuts. Judge for yourself, and let me know. And if you have a good name for it please let me know that too. Right now I'm calling it JSFSpy, but I really don't like that name.There is no dependency on JSFUnit. Installation just requires dropping a single jar into the WEB-INF/lib of your application. But you can do assertions on the collected data from JSFUnit or you can just browse it with the UI. If you want to use the UI, you'll need to put some xhtml files in your web app. Instructions are here.Here are the screen shots that should tell you exactly what it does. There's more stuff to add like Seam scopes, JSF2 scopes, component tree, and FacesMessages. What do you think so far?Main screen shows all HttpSessions ever created.Request view shows all Http/JSF requests for the selected session.Scoped Data view shows toString() value of each scoped attribute before and after each phase.HttpServletRequest view shows incoming URL, headers, request params, cookies, etc.Perf Data View shows which phases completed and how long each one took.[...]

JSFUnit goes GA


I'm very happy to report that the JSFUnit 1.0.0.GA release is now out!

JSFUnit is the only end-to-end BlackBox/WhiteBox testing solution for JSF. Your tests run in-container and out-container at the same time. That is, JSFUnit lets your tests submit real HTTP requests using a headless browser. Then it lets you examine all the artifacts inside the container including the FacesContext, Managed Beans, UIComponent tree, FacesMessages, and much more. And since you are running inside the real container you never need a mock object or stub. You never have to worry about constructing a fake test environment.

Most of you reading this blog have heard all that stuff before, so I'll just talk a bit about the GA release. Here are the main changes from the Beta 3 release.
  • The conversion to HtmlUnit is now complete. The old client side API based on HttpUnit is completely gone. Since HtmlUnit is far better at handling javascript, this means that most JSF AJAX libraries will work right out of the box. The notable exception is ICEfaces, and I've been working with ICEfaces team to get support for that as soon as possible.
  • We now have a JSFUnit deployer for JBoss AS5. I blogged about this earlier. This deployer lets you run your JSFUnit tests without making a single change to your WAR. Click here for details.
  • JSF 2.0 support. I know you are wanting to play around with JSF 2.0, right? Now you don't have to give up test-first development while you explore.
  • The last change is a bit of sad news. The two developers who were working on the JSFUnit static analysis tool have moved on to new jobs where they are no longer using JSF. I versioned the code to 1.0 along with everything else, but I do want everyone to be aware that new features and bug fixes for static analysis won't happen until someone else steps up. If you are interested in taking this on let me know. JSF static analysis is really cool stuff and it's a very useful tool.
Lastly, I want to thank everyone who helped make JSFUnit happen. This is a new kind of tool that required a lot experimentation before we got it right. It has taken much longer to get here than I expected. The community feedback has been great and I've gotten tremendous support internally at JBoss/RedHat. So, in no particular order, thanks to Brian, Dennis, Jason, Matt, Shelly, Julien, Kragoth, Wolfgang, Patrick, Dimitris, Farah, Sacha, Kito, Pete, Ed, Ryan, Alexander, Jesper, Neil, Ken, and a bunch of others I've probably forgotten.

So long, and thanks for all the fish,


JSF 2.0 and the upcoming GA release of JSFUnit


I don't work on JSFUnit full time. A big part of my responsibility at JBoss/Red Hat is to make sure that JSF and Seam integrate nicely with the JBoss Application Server.

So I've been looking at the JSF 2.0 Public Review release. Using JSF 2.0 with JBoss AS 4.2 and AS 5.0 seems to be just a matter of replacing jsf-api.jar and jsf-impl.jar. I'm sure that I'll come across some things that need more/better integration. And when I do, I'll have to implement something new. But for now I'm happy to be able to play with the JSF 2.0 PR release as-is on JBoss AS.

To see how much would run without error, I decided to go ahead and upgrade JSFUnit to work with the new JSF 2.0 API. That required adding methods to JSFUnitFacesContext and JSFUnitExternalContext. There were some other code changes, including a change to the Environment class that detects which version of JSF is running.

Anyhow, I'm happy to report that JSFUnit now works with JSF 2.0. You can download the latest JSFUnit snapshot if you'd like to play with it. The part of the JSFUnit test suite that doesn't run is execution of the applications that use Facelets and Ajax4Jsf/RichFaces together. I've filed a bug on it, so hopefully that problem will be resolved soon. Please leave me feedback on the JSFUnit Forum if you decide to give it a try.

Lastly, I've been asked several times when JSFUnit is going to go GA. There is really nothing stopping me now except that I'd like to fix a few more bugs and maybe add support for IceFaces. Look for a release in mid-February.

So long and thanks for all the fish,


JSFUnit experience required


The JSFUnit project has reached a new milestone. This is the first job posting I've seen where JSFUnit experience is required.

So long and thanks for all the fish,


JSFUnit the Easy Way!!


JSFUnit tests are easy to write and understand. This comes across clearly whenever I talk about it at a conference and I see faces light up. They "get it". However, it's also clear that the hardest part of JSFUnit is getting started. Once you get over that hump, developers really like the tool. But until now, setting up JSFUnit for the first time required quite a bit of work.

Enter the new JSFUnit deployer for JBoss AS 5. Now, here is all you need to do to set up JSFUnit for testing:
  1. Copy jboss-jsfunit-microdeployer.jar to /server/default/deployers
  2. Rename your war with a "-jsfunit" suffix (such as "mywar-jsfunit.war")
  3. Add your test classes to the WAR or put them in /server/default/jsfunitTests
  4. Restart JBoss AS 5 and run your tests.
That's it. In fact, with a simple edit to the deployer's descriptor you can even get rid of step 2.

This is all made possible because of the redesigned microcontainer of JBoss AS 5. You can take an ordinary WAR and add servlets, filters, and classes on the fly as it is being deployed. I've been wanting this kind of functionality for as long as I can remember. It's perfect for adding test tools, fixtures, or monitoring. Before now you had to bundle this stuff with the application - stuff that really doesn't belong in your WAR.

The interesting part is that now instead of thinking of a WAR or EAR as "my application", we can truly think of it as a reuseable deployment unit. It's just another component that can be decorated or combined with other components. While this view provokes a lot of questions (security, name collisions, etc.), the mind reels with the possibilities that this represents.

So long, and thanks for all the fish,


JSFUnit Beta 3 is out. Seam support and more!


JSFUnit Beta 3 is now released. Special thanks to our new committer Brian Gregory for helping with the conversion from HttpUnit to HtmlUnit as our client side technology (see previous post). Also, the HtmlUnit team has been very helpful with answering questions and providing bug fixes.

Click for details on new features. Unlike Beta 2, there are many goodies in this release, including support for Seam conversation scope!

If you are a Beta 2 user it is very important that you click the above link and read about the deprecated APIs that will be removed before GA. The next planned release will be 1.0.0.GA which should be out before the end of the year.

See this page for download information:
Keep all the valuable feedback coming. It is greatly appreciated!

See you at JSFOne next week.

So long, and thanks for all the fish,


Another JSFUnit Beta Coming Soon


And why we dumped HttpUnit for HtmlUnit

We will release JSFUnit Beta 3 before the start of JSFOne on Septemeber 4th. If all goes well, it will probably be out a week or so before that.

Originally, I planned to have the GA release out by now. But the opportunity to improve the JSFUnit tool was too great to pass up. That opportunity came in the form of HtmlUnit. HtmlUnit bills itself as "a headless browser". This is exactly what I've been searching for. That is, a way to truly simulate a user interacting with a JSF application - even one that includes AJAX components.

Up until now, JSFUnit used HttpUnit to submit client requests. And HttpUnit is good at that. But HttpUnit is old, and it's mostly a dormant project. It doesn't support the latest DOM specs. And worst of all, its javascript support is dismal. This makes testing JSF/AJAX applications very difficult. In fact, the javascript support was so bad I had to just turn it off. When testing a JSF/AJAX component I would have to simulate the javascript using Java and then formulate the resulting HTTP request myself. It became clear that it would be too hacky and time-consuming to keep doing things that way.

So for JSFUnit Beta 3, I've written a new version of the JSFClientSession class that uses HtmlUnit instead. With HtmlUnit, we can execute javascript and let that javascript submit to the server. No fuss, no muss.

HtmlUnit is still pretty new, so we've found our share of bugs along the way. But unlike HttpUnit, HtmlUnit has an active core of developers who are working closely with the JSFUnit team to fix problems quickly as possible. Thus, we're doing one last beta release instead of the planned GA.

For Beta 3, you can still use the old HttpUnit-based JSFClientSession and things will work fine. This allows our early adopters to migrate their tests to the new client one at a time. But HttpUnit will be completely gone from JSFUnit for GA. So you do need to migrate before then. The new stuff is in its own package called org.jboss.jsfunit.jsfsession. This replaces the old code in org.jboss.jsfunit.facade.

That's all the news for now. So long, and thanks for all the fish.


More JSFUnit on the Road


First Up, Jazoon '08
JSFUnit is hitting the road once again, but this time, it's not me doing all the hitting. Alexander Jesse of Credit Suisse will be giving a JSFUnit introduction at Jazoon next week in Zurich. If you are in Zurich on Tuesday, June 24th be sure to check it out. Jazoon offers one-day passes.
Click Here for More Details

Second Up, JSF One '08
I'll be doing at least one talk on JSFUnit at JSF One. This is the first dedicated JSF conference in North America. So if you are into JSF, you won't want to miss it. This is scheduled for September 4th in Vienna, VA (close to Washington, D.C.). And, you get two for the price of one because admission to JSF One also gets you into The Rich Web Experience conference.
Click Here for More Details or visit

By the time JSF One rolls around, we should have a GA version of JSFUnit out. But more on that later.

So long, and thanks for all the fish,


Cactus 1.8 is released


Congratulations to Petar Tachiev on the release of Cactus 1.8. This is the first release of Cactus in over 3 years. Thanks to Petar for taking over as project lead and getting a new release out the door. This release appears to cover mostly bug fixes and Cargo integration, which allows support of more containers.

He's also updated the build so that both Cactus and its web site are built using Maven.

See the Cactus Site for details.

If you've been following JSFUnit, you know that it is built on Cactus, so I'm very happy to see that project come back to life.

Life goes on for JSFUnit as well. The JSFUnit forum has been very popular lately and folks have been anxious to get their hands on a new release. So I'm planning a second beta release for next week. This will be mostly bug fixes, but it will include some new features as well.

Unfortunately, major new features like Seam support will have to wait for 1.0 final. We've made some progress, but it's not ready for prime time. Also, if you have a new feature that you really need in JSFUnit, make it known in the forum thread here. I'll do my best to make sure that new features are community-driven.

So long, and thanks for all the fish,


JSFUnit Beta 1 is Released !!!


As I write this I look at the title and wonder how many exclamation points I should have used. What I thought would be a tiny little framework has grown into a full-fledged project with a real beta release. We even have live demos.

JBoss JSFUnit is the first open source community dedicated to testing JSF applications. With this release, it is not one, but three different tools:
  • In-container Testing framework This is for testing both client and server side JSF artifacts. Test scope ranges from fine-grained tests of individual classes to full-fledged integration testing of a running JSF application. This is done with no mock objects, so you know you are getting reliable real-world behavior in your tests.
  • Framework for JSF Static Analysis testing This allows you to test your JSF configuration so that you find config problems early.
  • JSFTimer for performance testing of the JSF lifecycle This shows you how long each phase of the JSF lifecycle took for a given request. Of course, it also gives you total JSF lifecycle time. The JSFTimer allows you to write threshold tests that fail whenever a use case doesn't meet your performance standards.
If you want more info, read the other posts in this blog and then take a look at

But now a few more words about the release itself. First, it's called Beta 1. To me, that implies a few things. The first implication is that it's useful. Even before a downloadable release was ready, many developers built the project from subversion and started using it. So I know it meets my main criteria for a beta, which is that it fills a need. It's useful, so by all means, feel free to use it.

The second thing about being a beta release is that it's not done. That is, we know some features are missing. Mainly, JSFUnit needs support for more Ajax components and it needs more deployment tools.

The last thing I want to say about the release is "Thank You". First, thanks goes to Dennis Byrne of ThoughtWorks and Matt Wringe of JBoss. These guys contributed code to the project and continue to be active. We need more help as demand for bug fixes and new features has ballooned even before we ever released. So if you want to help out just send me an email or post on this blog and let me know how you'd like to get involved.

Second, I want to thank Julien Viet, JBoss Portal lead, and Patrick McDonald, my manager at JBoss/Red Hat. These guys have given the high level support that made it possible for me to work on the project in the first place.

Lastly, thanks to all who have been the early, early, early adopters. Your feedback on the JSFUnit forums and through email have been invaluable.

So try it out. Let me know what you think.

So long, and thanks for all the fish,

Stan Silvert

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,


Introducing JSFUnit


A few months ago, Julien Viet, creator of JBoss Portal, sends me an email. He says, "Hey JSF guy, why are there no good testing tools for JSF? I need a tool for this. Maybe you can help?"I took a look and he was (mostly) right. There are a couple of mock object frameworks for JSF as part of Shale and Seam but they are there primarily for testing artifacts you might create for those frameworks. They are really not general testing tools for JSF applications. And they don't help with integration testing at all.So I started thinking up what a general JSF testing tool might look like. Here is what I came up with:No mock objects!!! I really hate mocks. I hate writing mocks. I hate maintaining mocks. And I hate knowing that my mocks don't simulate the environment well enough. But most of all, I hate it when I have to add stupid init() methods to my application code - just for the mocks. And sooner or later I know my tests will fail because of the mocks! BTW, here is a saner discussion of Mock vs. In-Container testing.Leverage the JSF API JSF provides tons of information about a running application. If I want to assert that my JSF application state is correct, I should be able to just ask JSF.Use plain old JUnit If I want anybody else to use the tool, they shouldn't need to learn how to write tests all over again. JUnit has stood the test of time. It works well and everybody knows how to use it.Allow navigation testing A big part of validating JSF is validating that a given user input will navigate to the proper page view.Test a JSF App as it is really deployed and run I suspect that this is why nobody has built a full JSF testing framework yet. A real JSF request might start with an AJAX component that fires an HTTP request, then pass through servlet filters, hit the FacesServlet, the JSF lifecycle, a myriad of PhaseListeners, do magic Seam stuff at every turn, and then all get rendered with Facelets. How can you possibly test all that stuff together with a mock framework?So it has to be an in-container thing like Apache Cactus. But Cactus would have me instantiate a FacesServlet and call it directly. That won't quite cut it. What I really need is something that runs in the browser to do real HTTP requests and some kind of JUnit test on the server that lets me do asserts when the request is done. Why not a JUnit test that does both at the same time in the same JVM? Then I can assert that the server side state is correct and the client state is correct - all in the same test.JSFUnit is doneI just combine Cactus and HttpUnit and I'm done, right? It took six classes to tie it all together. Cactus lets me run JUnit tests in-container. I can make real HTTP calls with HttpUnit, then test the HTML that comes back. And with a few FacesContext tricks, I have access to all the real server-side JSF objects for navigation, managed beans, EL, the component tree, etc. So I can do real JSF requests, test the real HTML that comes back, and test the real state of the real server-side objects.For real. All in one JUnit test.Only six classes. All that and only six little classes! Julien will really like it.Julien hates it"Stan, this sucks." OK, he didn't exactly say that. At JBoss, they don't just come out and tell you your code sucks. They use a lot more cuss words and throw in an SMD or two.He told me it needed a simpler API and he was right. I wrote some Facade classes and got a Hello World test down to about five or si[...]