Discussions

News: JBoss releases JSFUnit 1.0 GA: End-to-end JSF Testing

  1. JSFUnit 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 Managed Beans, FacesContext, UIComponent tree, FacesMessages, and much more. For client side testing, we provide a simple API based on HtmlUnit. You can even assert client state and server state in the same test. So you can have tests that say things like, If I submit this form, make sure that the browser shows X and my managed bean has a value of Y. 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. JSFUnit can be used with JSF 1.1, 1.2, and 2.0. It works with all servlet containers that support JSF. Recent new features include:
    • Examine beans in Seam conversation scope
    • Full support for most JSF AJAX libraries
    • JSF 2.0 support
    • Easy navigation through login screens
    • Complete javascript and XPath support
    Click here for the JSFUnit home page. Click here for the JSFUnit documentation. Stan Silvert http://www.jsfunit.org
  2. Thats very good work and we have already started leveraging this. GUI test cases has a huge potential and this will bring lot of value addition to enterprise apps built on JSF. Its pretty simple infact. This is a great value addition to JSF and JSF 2 stack. Good Work.
  3. Any relation to SeamTest?[ Go to top ]

    How does this framework differ from it's stablemate SeamTest? Presumably it doesn't need Seam. Is it a subset of SeamTest or does it contain different features?
  4. Re: Any relation to SeamTest?[ Go to top ]

    JSFUnit is an in-container superset of SeamTest. SeamTest is especially well-suited to testing Seam components in isolation. SeamTest also has a simulated JSF lifecycle that you can use for quick and dirty integration testing. Of course, SeamTest runs a little faster because you don't have to start the container. But that's becoming less of an issue as many containers these days can start in 5-6 seconds. With JSFUnit, you can literally test every part of your application in its true deployment environment. You get a real HttpRequest/HttpResponse and you run through your chosen JSF implementation with all its associated servlet filters, phase listeners, etc. All the artifacts, the HTML, the request/response objects, the managed beans, the FacesContext, and the database, are available for assertions. So the way I see it is that you should use SeamTest for isolated testing of Seam components. You can also use it for limited integration testing if you don't mind setting up the mock environment. Use JSFUnit for everything else. Stan http://www.jsfunit.org
  5. Re: Any relation to SeamTest?[ Go to top ]

    Thanks. This is useful additional information that you could add to the project home page at http://www.jboss.org/jsfunit/.
  6. Re: Any relation to SeamTest?[ Go to top ]

    Thanks. This is useful additional information that you could add to the project home page at http://www.jboss.org/jsfunit/.
    Thanks for the suggestion. I put the answers in the JSFUnit FAQ. Stan http://www.jsfunit.org
  7. It will be nice if you can also share your view how this differs from what we can do with Seleniuum. Can both be integrated? In RF jars I see selenium xmls also.
  8. Selenium is purely for black box testing. That is, Selenium only gives you the client side view of things. Also, Selenium uses native browser code. That can be good or bad depending on your perspective. JSFUnit uses a pure java headless browser (HtmlUnit) that can emulate different versions of Firefox and IE. It has an API on top of HtmlUnit that understands JSF views. So the client API is a little easier to use than Selenium. I'm obviously biased, but I think JSFUnit is a far better choice for developers because it allows you to do comprehensive white box testing as well as the black box testing that Selenium provides. As for using both JSFUnit and Selenium, you can run them side-by-side as part of your test suite. But there is no formal integration. Stan http://www.jsfunit.org
  9. first things first: Congratulations for going live with 1.0.0 One advantage of Selenium(Remote Control) is that it uses a simpler API. Something like selenium.click("link=Do Something"). And using the FireFox plugin for Selenium you even can export a Java-source from your recorded scripts. This positions Selenium more on the "beginners side" of JSF-unit testing. When you do some intensive testing on complex applications, though you soon hit the walls... Because you need to check some internal application state to be sure everything is ok. That's where JSFUnit will help you... being a transparent-box test tool. And with the static tests it can help you to automate upfront-checks which are normally covered by the IDE's (correctly writing the config-files,...) but with IDE's you cannot really to automated builds. With JSFUnit you can add an additional check to your build.