wood burning stoves 2.0*
The moose likes JSF and the fly likes How does JSF accommodate automated testing? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "How does JSF accommodate automated testing?" Watch "How does JSF accommodate automated testing?" New topic
Author

How does JSF accommodate automated testing?

Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
One of the most important factors determining my comfortability with any given technology these days is, how easily can I test the code related to that technology without waiting for a massive infrastructure to crunch through deployment archives and starting services I'm not going to need.

What's the state of the art for testing JSF stuff?

I'd be especially interested in hearing the authors' and other JSF users experiences and opinions on whether it's feasible to unit test (test-drive, preferably) JSF components/pages (and how/with what tools)?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
I just got this lately from Jeff. Shale Test Framework.

Struts Shale is based on JSF.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Thanks for the link, Adeel. I wasn't aware of Shale having such a test framework. In fact, I couldn't even remember that Struts Shale is based on JSF...

I did get the perception, though, from reading the page that there's support for testing JSF components (through a library of mock implementations of the key JSF interfaces) but that there might not be much support for unit testing the JSF "pages" as such. Is that correct?
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by Lasse Koskela:
.... there might not be much support for unit testing the JSF "pages" as such. Is that correct?


The Shale Test Framework provides mock object libraries, plus base classes for creating your own JUnit TestCases.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Adeel Ansari:
The Shale Test Framework provides mock object libraries, plus base classes for creating your own JUnit TestCases.

Yes, I read that sentence from the website. The question remains, does that mean there is no support for testing the end-to-end rendering of a JSF page?
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by Lasse Koskela:
The question remains, does that mean there is no support for testing the end-to-end rendering of a JSF page?


Ok now I got you. Can't say anything about it, because even I never used it. I am just looking at it in my leisure time. Please excuse me.
[ April 06, 2006: Message edited by: Adeel Ansari ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I didn't mean to imply in any way that you'd be somehow obligated to answer my question. I appreciate your taking time to have this discussion here even if I'd log off without all the answers
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Bumpin' this up in the hopes that the book promotion thing had scared away some "regulars" or otherwise stole attention from my topic...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:

Yes, I read that sentence from the website. The question remains, does that mean there is no support for testing the end-to-end rendering of a JSF page?


Interesting question. What exactly would you want to test?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
What exactly would you want to test?

The thing is, I don't know.

I haven't yet used JSF myself and know very little of it. I'm just trying to get a grasp of what's the state-of-the-practice with JSF. In other words, I'd like to know what is technically possible to unit test in JSF and with what tools/libraries?
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Lasse, there are a couple of things you might want to test on a JSF:

-converters
-validators
-datatables
-dates
-panelGrid (this style wise)

Pretty much everything on a JSF gets mapped to the backing bean's attributes or methods. So if you want to test that just create a managedbean and run it inside a JUnit test. Punch in some data, call the action method and see what it returns. That's pretty much a no brainer. You can test just about anything that way, did I have the proper output, did I have the right select options etc. Overall your whole navigation schema can be tested inside a unit test.

The tricky part for me at least has been the actual output. Am I getting all the values right and most importantly is it getting validated well. Dates and selects have been my bogey man. You have to create these converters for anything other than strings in a select menu. Without them it just doesn't work period. And JSF error messages are awfully cryptic. Some unhandled exception in your code can create an error that looks JSF related, but is actually some problem with your action method or your converter.

So basically for me the process goes like this (specially if your new to JSF and don't fully understand the beauty of it ) :

-Get and idea of what your view is going to look like
-Create some dummies with the widgets you'll be using (text input-output, selects, buttons, links (these last ones can be really tricky). Test them with a dummy managedbean that does some sort of System.out.println. Quick and simple.
-Evolve these dummies into a full blown page and test again with the managed bean (might want to put some more sophisticated logging here now). Check your converters and validators with some sample data.
-Then unit test your converters and validators if they're not stock JSF.
-test again with the JSFs
-put id tags in your JSF elements and styleClass tags too
-render the page into HTML and edit with your favorite html editor till it looks ok
-send those sytle changes back to your application
-fill your test managedbean with data and test how it looks specially changing stuff based on a render flag. This can make some rows disapear and misplace your styles (given the way panelGrid and dataTable work with styles)
-I'm working on getting some type of JWebUnit and dummy managed bean testing suite going for this stage. To automate the input validation part, but graphically you just have to look at it.

After I know the view works I ditch it and work directly on the managed bean and navigation rules. Since all button clicks and link clicks will create a string response doing an assert is pretty easy thing. You can move your managed bean to a state, say page two and start filling info with getters and setters (which would be the values of the JSF elements), "click" action methods and assert outcomes.

It would be really nice to read the faces config xml file and test the navigation rules, but I haven't found nor developed a way to do that. So I pretty much code the flow into the JUnit tests.

Things I'd like to finish doing
-use JWebUnit and a dummy managed bean to test what is going on. They'd be interconnected someway (maybe dbase wise). JWeb gets a page, asserts options (say selects, radios, pre filled fields) and posts data. The bean asserts the values (check converters and validators). JWeb asserts non compliant input in the response (in case of failed validation). The bean returns the response and JWeb makes sure it was the page as set in the navigation rules.
-a pure JUnit test that can navigate given the rules and using just the managed beans. This would be more of an acceptance test than a unit test, but never the less something worth having.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Thanks for the description, Gerardo.

Regarding the jWebUnit tests, I assume you're running them by deploying the application on a local installation of an application server? May I ask which server and whether you deploy from the IDE or with a build script and what's (roughly) the duration of the usual make-the-change-redeploy-and-run-tests cycle?
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Yes I'm running locally. My setup is the following

Eclipse + MyEclipse

MyEclipse handles all the local deployment, although applications are finally published as war files.

Tomcat 5.5

I work on a PowerBook G4 with 1.25 Gigs of RAM.

The make-the-change-redeploy-and-run-test cycle takes way too long. From the moment you hit save and build to the test START you can spend between 30 sec to 2 minutes. Usually about 40 secs. What really takes up time is the application powerup. If you have many apps that depend on each other you build up time quick. Consider load, init serlvets, start Hibernate then translate and compile JSFs. Of course after many failed deploys Tomcat can run out of memory and then you need to do a full restart.

Yet in the early stages of the application or with just the views (JSFs) things run about two or three times faster. So that is why I emphasize the test the JSFs in dummy apps and by themselves. It is the point I'm trying to integrate the JWebUnit idea. Weed the JSF bugs out quickly. Then test the managed beans. Every JSF build is extremely expensive in time. Say on an average I can fix 20 JSF bugs in an hour at best. So I want them to be real JSF bugs not some wierd exception or Hibernate issue that manifests itself as a JSF bug.

I really recommend some sort of JSF aware XML/JSP editor. Deploying only to find out you missed a closing tag just drives you nuts.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I once managed to use a combination of JDemo and Jetty to display a JSP in a matter of a couple of seconds without any deployment necessary (very rudimentary, though). I wonder whether something like that could be made to work with JSF pages - and whether it would be worth the effort...
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
I once managed to use a combination of JDemo and Jetty to display a JSP in a matter of a couple of seconds without any deployment necessary (very rudimentary, though).

Hmm. What was JDemo's role in this setup?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:

Hmm. What was JDemo's role in this setup?


(Sorry, I misremembered (is that a word?) - it was a servlet, not a JSP.)

It simply provided the glue code, and a convenience method to show the content of a file. So what I did was deriving a ServletDemoCase that rendered the response to a get request into a file and let JDemo present its content: http://cvs.sourceforge.net/viewcvs.py/jdemo/JDemo_internal_CctrlLamp/src/de/jave/cctrl/lamp/demo/ServletDemoCase.java?view=markup

Writing the demo itself then was a piece of cake: register the servlet with the servlet runner, set up the environment and specify the get request to use: http://cvs.sourceforge.net/viewcvs.py/jdemo/JDemo_internal_CctrlLamp/src/de/jave/cctrl/lamp/demo/WebBuildStatusViewDemo.java?view=markup
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Anybody here used Cactus? Looks like a way to solve some of the testing issues with JSF too.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Gerardo Tasistro:
Anybody here used Cactus? Looks like a way to solve some of the testing issues with JSF too.

I've used Cactus a long time ago. It kind of solves some of the problems, I guess, but at the expense of speed--you have to deploy the whole application before your tests.

I'm secretly hoping for someone to spill the beans on a cool unknown unit testing framework that lets people test all things JSF outside of a container, in the comfort of their IDE, in a matter of one or two seconds rather than 30-120 seconds per test run. I guess I'll be secretly hoping for a long time
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Lasse Koskela:

I'm secretly hoping for someone to spill the beans on a cool unknown unit testing framework that lets people test all things JSF outside of a container, in the comfort of their IDE, in a matter of one or two seconds rather than 30-120 seconds per test run. I guess I'll be secretly hoping for a long time


The more effective strategy than waiting would probably be to *build* it...
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ilja Preuss:
The more effective strategy than waiting would probably be to *build* it...

True. And the thought has already crossed my mind several times with jsptest...
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
One of the main issues with testing JSF outside the container is the lack of the managed beans and FacesContext. This might not be an issue in simple pages, but if you use complex converters in might. I've seen situations in which the FacesContext is used inside the converter to access object attributes. Say for example you want to create a dessert selectOneMenu and you need a bean of RestaurantMenu type. From it you get the list of possible desserts of Dessert type. And you use the converter to convert from the select's string values to the Dessert type and place the selection in your order menu.

Got no idea how that could be solved outside the container.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
You'd probably have to mock some of the infrastructure (such as the FacesContext). Not sure how hard that would turn out to be.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Gerardo/Ilja, the Struts Shale project has a "test framework" which includes some kind of mock implementations of what seems like the majority of javax.faces.* interfaces/classes. I don't know how easy it would be to use those classes for building such infrastructure, however.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How does JSF accommodate automated testing?
 
Similar Threads
Unit Test Tool for JSF Portlets in websphere portal5.1
icefaces 1.8 and ajax push
For Mr. Cohen: Testing Java vs. testing .NET
Unit Testability ---JSF
JSP newbie