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,

Stan

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,

Stan

*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,

Stan

What's a WARlet ???

JSFSpy Progress
Today 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:
http://www.jsfcentral.com/articles/silvert-08-09.html

I'll be speaking at the conference again this year in Orlando. Hope to see you there.
http://www.jsfsummit.com

So long and thanks for all the fish,

Stan

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,

Stan

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.