JSF Central - Stan Silvert on Testing JSF Applications with JSFUnit
JSF Central

 Articles & Books 
Community Chat
Stan Silvert on Testing JSF Applications with JSFUnit
by Kito D. Mann
25 Aug 2009 00:00 EDT

In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Stan Silvert about JSFUnit, an open source integration testing and debugging framework for JSF applications and JSF AJAX components. This interview was recorded in September of 2008 at JSFOne.

Podcast (MP3)
Welcome to the JSFCentral podcast #16 for the week of August 17, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology.
Kito Hello, my name is Kito Mann and I am here at JSFOne 2008 day number 3. I am here with Stan Silvert who is one of our speakers. Stan works at JBoss where he works on JSFUnit, and you are actually in the application group? Is that right?
Stan Technically I am in the application server group. My primary responsibility is integration of JSF and Seam into the application server. I have lots of time for JSFUnit which is my number 2 priority right now.
Kito Before we get into JSFUnit, tell us a little bit about your background -- what you do at JBoss in a little more detail, but also what you were doing before you ended up at JBoss.
Stan Before JBoss I bounced around to a lot of different companies. Like a lot of developer architect types, you go from project to project and JBoss was actually the tenth company I have worked for in my career.
Kito As an employee?
Stan As an employee. I have never done contract work; I have always been an employee.
Kito Wow!
Stan I have been with big companies, small companies, and little bitty startups, some that did well and some that went bust. I have had the whole gamut. I’ve been at JBoss for about four and a half years now. That is my longest tenure.
Kito Fascinating. So at JBoss, obviously you haven’t always been involved with the application server in Seam because it hasn’t been around for four and a half years. When you started there what were you working on?
Stan I got myself in the door as the first support engineer that JBoss had. JBoss always had a philosophy of hiring architect types to do the support. In fact we still do that almost exclusively today, because it is usually the architect that is talking to us when they have a problem with JBoss, so we always wanted a high level of support. I wanted to get into JBoss because I knew it was going to be big. That was a way to get my foot in the door. I did that for a year, year and a half, and got into JSF. I was the only person at JBoss who was really interested in JSF at the time. I started to do more and more with that and worked my way into a full time developer role.
Kito Hmm, interesting. So let’s talk a little bit more about the work you are doing now. You are doing work, ensuring that JBoss and Seam work in the application server and you’re not involved with the portal side of things at all -- just the application server?
Stan No, not much. Early on I did a little JSF portal work. I did the original MyFaces Portlet Bridge, but I don’t do much with portal anymore.
Kito What sort of challenges have you seen in terms of making sure that Seam and everything works well with the application server?
Stan I’ve actually just taken that over. There are some JBoss specific things with caching that I have to start looking at when I get back from this conference, and so anything that is JBoss specific, we want to make sure it gets pulled completely out of Seam and into the app server. There is a little bit of porting work to do there.
Kito The JBoss application server uses the JSF reference implementation, right?
Stan That’s correct, Mojarra.
Kito Yes. Everyone here who is on the actual Mojarra development team has made it very clear that we are supposed to call it Mojarra, not the JSF implementation. Mojarra sounds cooler -- I think people just don’t know it yet, that’s the problem. So were you involved in making sure the JSF stuff worked?
Stan Yes. I worked on MyFaces and actually worked on MyFaces core. The original idea was to bring MyFaces core up from 1.1 to 1.2 so I started that project and got about halfway through it when Mojarra, MyFaces RI, went open source. So we were able to take that finished product and put it in there. There was a fair amount of integration work that needed to be done to make it work seamlessly with the JBoss application server.
Kito So if someone gets JBoss, I guess 5 is the one that has the RI in it?
Stan Actually we started the RI with version 4.2.
Kito Okay, so if you download 4.2, it includes RI. Have you had any issues with people trying to use different versions of JSF or anything like that?
Stan Yes, the way JSF has historically been deployed it is that you put the JSF runtime as part of your WAR. People will put MyFaces in their WAR and then try to deploy on the JBoss application server and you will start to get class conflicts with the RI. I did put a switch in there that lets people do that so it will only load MyFaces, it won’t load the RI. It is not a supported feature because we only support what ships with the app server, but if you are using the community edition there is that switch, and it works fairly well if you want to just run MyFaces for some reason. Frankly there is no reason to do that. I have not found a legitimate reason to bundle the JSF runtime in your WAR anymore. You should use the one that ships with the app server, it runs much smoother.
Kito Right. It’s really more for situations like if you are deploying on raw Tomcat or Jetty -- some plain web container.
Stan Exactly.
Kito So you have done this work with application server integration with JSF and related technologies. Earlier this year this new project called JSFUnit popped up, right?
Stan It was about a year ago. The lead for JBoss portal sent me an email and said “hey JSF guy, why is it so hard to test JSF applications? There are no good products out there. I can’t do what I want.” He had this list of complaints so I said “let me see what can be done” and I took a little research project -- about two or three weeks -- and after a couple of failed attempts to do what I wanted, I finally figured it out and came up with JSFUnit, which is an end to end in-container testing tool that requires no mock objects. You write simple JUnit tests, and you can do your asserts on anything from what the user sees in the browser all the way through to all the JSF artifacts like Faces Context, your managed beans, your component tree. You can even take a look at what happened to the database after each request. It is very powerful. I am very pleased with how it turned out.
Kito So the portal spec lead is Julian Reschke, right? So was he happy with the result? Is he satisfied now?
Stan He liked it and the Seam team is starting to use it as well for testing all the Seam example apps to make sure that they work.
Kito Cool.
Stan The community has just been great. I have been flabbergasted by the number of people in the community who are using it and liking it. It is still in beta and I am not satisfied with it yet. I am not happy enough with it to call it GA but yet I have all these people in the community who are using it, so that has been very satisfying.
Kito So let’s say I am writing my JSF application and I decide I want to get JSFUnit and I download it. What do I have to do? Let’s say I want to test…like a login page and I have written my backing bean and have some components on the page and I want to test that it works OK.
Stan What you do is get the JSFUnit JAR, of course with several supporting JARs. There is a “getting started” page -- if you go to jsfunit.org you can see all this step by step. You get the JARs, you do make some modifications to your web XML to set up a couple of filters and a couple of extra filters that are used by Cactus, which is what we use to do the in-container magic for JUnit. Then you write your test, which is usually very few lines of code. You have a JSF client session and a JSF server session so you use the JSF client session to click things on the page and you input things on the form and such as that. Then every time there is an HTTP request you can go to this JSF server session object and look at all the things on the server, like the value of your managed beans. Did the value really make it into the managed bean like you expected? Did the component tree turn out the way you expected? It is a very powerful way to do assertions instead of having to do assertions on the HTML – which is something we still allow you to do – but really a better way is to assert that the JSF component tree turned out right. Because that is what your logic actually took care of. Like I say, it’s not many lines of code to write tests to test things.
Kito Cool. You mentioned Cactus there. Tell the listeners where Cactus fits in, what’s happening here? It is really kind of cool that you are able to assert what is happening on the server and also what is happening on the client in the same unit test in just a few lines of code, so there must be some magic happening.
Stan There is quite a bit of magic, yes. First off Cactus is a fairly old Apache project that has just been recently revived and taken over by a guy named Peter Tahchiev from Bulgaria, and he has just done a new release of it.
Kito I didn’t realize that.
Stan So Cactus is starting to flourish again. What it allows you to do is to run a JUnit test that looks like it is running locally, but it is really calling out to the server and running the test inside the server. That is essentially what Cactus does. So we take advantage of that in JSFUnit. The magic happens where you have got your test running inside the server and it creates -- using another project called HTMLUnit -- it creates a real HTTP request that just goes out and back in to that same server and hits your real application with all the real configuration that you would have done with filters and whatever else. After things are done with the request, instead of destroying the Faces context, it keeps it around and associates it with your test thread. So now I have access to the Faces context, which means I have access to the world and I can look at everything. That is really the secret sauce.
Kito Ok Cool. So you have this HTMLUnit…
Stan HTMLUnit is used for the front end. HTMLUnit is a headless browser that is coming along very nicely, has a very active community. That is what allows me to also deal with Ajax components. HTMLUnit will run JavaScript natively. It is a full fledged headless browser that can impersonate Firefox or IE and a few different versions of those browsers. It is pretty nice. We recently switched to that. We were using the older HTTPUnit for the front end stuff, but with beta 3 we are using HTMLUnit and we have much better Ajax support and things are looking good.
Kito So this means that if I am using RichFaces or something I can actually test the Ajax behavior?
Stan Yes, you can do all that. When you click on something with HTMLUnit, it is just like the user clicked it with their mouse, and whatever happens to the DOM on their side happens, and whatever HTTP request gets sent to the server, it happens exactly like it does when a real user is using the system.
Kito That’s great. So how complete is the JavaScript support?
Stan It’s very complete. It uses Rhino, I believe. It’s not perfect, we run into bugs now and then, but like I said that community is very good, and they are very good about fixing bugs when we find them so I have been real happy with it.
Kito JSFUnit currently works well with RichFaces. What about other Ajax component suites?
Stan Right now we haven’t done a lot of testing with the other component suites. Before when we were using HTTPUnit, it completely would not work with anything but RichFaces, and we had to write a whole lot of custom code to make it work with RichFaces. With HTMLUnit other component libraries should work out of the box, but now we are in a position where we can look at other suites like ICEfaces, Trinidad, and Tomahawk and start making sure that all the components behave properly with HTMLUnit.
Kito Ok, so one of the other features I really like about JSFUnit is the static analysis. Why don’t you tell us a little bit about that?
Stan Yeah, I skipped over that -- I should not have done that. Static analysis is a way to examine your code or application without running it at all, and just be able to inspect what you have written at the source level and determine if you have any problems. For JSF, static analysis that you can do usually has to do with the composite configuration -- that is I pull in all the faces-config XML files from wherever they may be. As you probably know if you install different component libraries, it has its own faces-config in a JAR that gets read, or Seam has a faces-config that gets read. You pull all of those things together and you come out with a composite configuration of your application. If you take that plus the markup – either the JSP or XHTML file if you are using Facelets – JSFUnit will look at that all together and try to find common problems, things like an EL expression that doesn’t really point to anything. It can find things like if you declared two managed beans with the same name, which can be a big problem. If you have misspelled the word session or something like that in one of your config files, it will find that. Then just a number of other common things, and we are trying to add new checks to that all the time so it lets you find bugs early. Some of them that it finds, you would never know until maybe production if you didn’t run some of that static analysis.
Kito Especially if you don’t know what is in the JAR files in your class path.
Stan Exactly.
Kito Anything else you want to add, Stan?
Stan There is one other thing we do. We do a little bit of performance analysis – we have a little performance analysis tool that measures the time spent in the entire JSF lifecycle, or you can bring it down to the phase level. I can say “I expect the application phase of this request to always take less than two seconds,” and you can write a test that says that. So there is a little performance analysis. We are going to be adding some things to that as well. We are going to eventually add something that measures EL performance, because we found that has been a big bottleneck often times, especially when you have a large number of EL expressions on a page, such as when you have a large data table or something. That EL performance often tends to be a bottleneck, so we will be able to measure that in a JSFUnit test.
Kito Cool. I definitely appreciate you coming out to the conference, Stan. It is always good to have more testing perspectives. I’ve decided that testing needs more focus in JSF.
Stan It does. You ought to be able to do test-driven development in JSF and that was my goal, really: to make a tool that allows me to do test-driven development, true test-driven development. It has been good. Thanks for having me here and for putting on the conference. It’s been a great conference.
Announcer That’s it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann.

RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.