I'm trying to find a practical unit testing framework for JSF.
I know about JSFUnit, but this is very impractical to me. I need to include about 10 JARs to my project, and jump through many other hoops just to get it running.
I realize that -- due to the need to simulate a platform and a client -- unit testing web applications is difficult. But is there a better way?
Have you thought about doing integration testing with Selenium or another tool? Selenium allows you to record and run tests directly in the browser. You can also run tests in multiple browsers and on multiple platforms with Selenium Remote Control.
Writing unit tests is good, but it might provide more to create some functional integration tests rather than unit-testing the presentation layer code.
On the project I'm working on at the moment we dabbled with using selenium. We actually spent a lot of time writing these selenium tests, but found that they added little value because the UI changes so much and you just end up doubling your effort for very little return on investment.
Another problem with selenium is that it requires your code to be deployed, which means it doesn't play well with unit test frameworks eg maven.
What I would say is that writing really good unit tests for your managed beans is invaluable.
Have you taken a look at the jsfunitwar Ant task or alternatively the Maven plugin provided by JSFUnit? Both greatly reduce the complexity of generating the .war file to be tested. I'm using JSFUnit on my current project and find the combination of white box and black box testing capabilities to be very powerful. Because JSFUnit uses HtmlUnit under the covers, you can very easily and effectively examine the generated HTML, or conversely, verify the state of your internal JSF backing beans. I was able to incorporate the JSFUnit tests into my Continuous Integration process and have been quite pleased with the outcome.
HttpUnit can also be an alternative. It provides apis so you have a choice to automate the tests.
http://httpunit.sourceforge.net/index.html
Selenium is superficial, jsfunit is inward. I recommend that use jsfunit if project is not simple. Because team member can change jsf managedbean names or etc, you can catch that with jsfunit.
I'm with Paul on Selenium being very easy to setup and start working with. I use Selenium IDE in Firefox with some customization at that level, then you can export these to other platforms such as Java JUnit tests. It was quite easy to download and launch the selenium-server.jar, add the selenium-java-client-driver to my existing Eclipse Maven POM driver project; then launch the same exported JUnit test in Eclipse. I mainly wanted to use Java just for looping which the basic Selenium IDE didn't support.
I have configured JSF Unit for my project too which does require more time to configure... more importantly though with in-container tests like JSFUnit changes to the test require rebuilding the WAR, redeploying in the container and then executing from Eclipse or via a browser. So for quickly trying a small change this is time consuming. Of course with JSFUnit you have access to all the internals of the JSFSession etc so it depends what granularity of testing you need I guess.
I'd be interested if anybody knows a faster way to turnaround changes to a JSFUnit test and execute it. Definitely Selenium tests feel more like JUnit tests in that regard.
Related
What are the parameters to do the POC of the application and making sure it's right candidate for Selenium Automation and then how to begin from there?
If you know your goals, then the issue is to show how Selenium can achieve those goals.
If you don't know your goals, then every tool is the wrong tool until you know what it is you wish to accomplish.
Selenium is good at automating testing of web applications across multiple different web browsers. Some aspects of that testing are better than others, and all of those tests will be written by the testing team that leverages Selenium to verify the application's correct appearance or functionality.
If you have a web application, but don't know how you might test it (possibly because you don't have a test plan) Selenium won't provide a good test plan. It will just provide a set of tools that make some test plans much easier to implement.
I think what business problems selenium solves in that application.
I've been asked a question by one of our developers here. They are asking whether it is possible for a selenium test suite to be tied in with a TFS build in visual studio to the test server? So that way, as soon as a build is done it can kick off a run of the regression test suite, directly after that.
Bear in mind that my scripts have been written in Eclipse, NOT Visual Studio, so I'm not sure if this will cause restrictions.
You can call UI scripts as you describe and I would additionaly recommend that you use Release Management to do this rather than build. It makes much more sense to use a deployment engine rather than a compilation engine to maintain this. One does not usually have an instance of ones application running on the build server.
http://nakedalm.com/execute-tests-release-management-visual-studio-2013/
You need to get a few things lined up, but it worked pretty good..
Are you supposed to run automated integration tests against a QA server or are you supposed to somehow start an application server from your tests? Does anyone do option #2? How are you supposed to start an application server from tests?
I'm just running into the dilemma of not knowing where to point my selenium driver to. This is a spring java app.
Are you supposed to run automated integration tests against a QA
server or are you supposed to somehow start an application server from
your tests?
As a practical concept, at least the way I see it, the more your test environment(s) looks like your production environment(s), the better. It means that even hardware, location, operational system, etc, have to be considered.
It all comes down to how much "effort" the project is willing to invest on the quality of the product.
You are supposed to run automated integration tests based on your product and project contexts. There isn't a single and final answer to your question, because there are a lot of variables that have to be considered.
Does anyone do option #2?
Yes, I do use a embedded application server but I only used it for database integration but you can apply that for functional automated testing as well.
How are you supposed to start an application server from tests?
One option is to use embedded containers that you can manage with Maven profiles. I recommend you to follow this Arquillian Getting Started guide to understand how it works, and then you can apply the same concept for Selenium and Spring.
I usually go with option 2 -- I use the Maven Jetty Plugin to start an application server running the webapp (usually under a 'test' profile to swap out certain dependencies like the database) and then run Selenium against the locally hosted application. You can bind the Jetty plugin to pre-integration-tests, and stop it in post-integration-tests.
I typically also include the JaCoCo plugin to instrument the Jetty JVM so that I can check coverage from Selenium-style integration tests.
I've been looking for a code coverage viewer aimed at inspecting live Java applications, mostly webapps running inside an application container like Tomcat. Sure, there are a number of decent tools for getting automatic reports of unit test coverage, but my aim is more like learning in real time what an unfamiliar Java app does e.g. on a specific user interaction.
The Eclipse Java debugger (with JPDA for remote debugging) is really useful, but only if you are already familiar with the application's architecture. And in theory, I could take some coverage tool and set it up to auto-refresh static HTML coverage reports every two seconds, but this is far from optimal.
For Adobe Flex, FlexCover does just what I want by providing a coverage viewer tool that visualizes the coverage in nearly real time, and it's relatively simple to set up at least for somebody who knows the stuff. So is there a similar easy-to-set-up GUI tool, free or non-free, for Java?
You can view Clover's coverage data generated by a web application, in Eclipse, without the need to start the web server from Eclipse.
The trick is to configure the initString in the Eclipse Clover Config screen to point to the same clover.db that your webapp is using:
And - you need to ensure you are using a threaded flushpolicy. The clover-maven2-plugin uses one by default. If you are using Ant, you will need to set it explicitly on <clover-setup/>.
You must also ensure you are using the same version of Clover in both Eclipse and your build tool.
I have tested this locally - and it works quite well!
Please let me know how you go.
Have a look at clover. It may be what you are looking for. Not free, but nice.
We're migrating our application into a Java EE container, and looking for tools to use for unit testing (and integration testing) our migrated app.
Our requirements include:
Ad-hoc testing: the ability to run tests manually, on demand (to be used by developers while developing code)
Batch testing: the ability to run a large (and growing) set of tests regularly
In-Container: integration tests that use EJBs as they are deployed in the container
Unit testing: Testing of classes not necessarily inside an EJB context
Nice to have: Simple to set up, integrates with ant/IDE
No requirement to test Servlets/JSPs - only POJOs and EJBs
What are you using to achieve testing in Java EE environment? What technologies/setup have you deployed?
My research have uncovered Cactus and JUnitEE: have you had success setting them up?
We use normal JUnit for both unit tests and integration testing. We switch between the two using a VM argument, and have the tests annotated with markers for direct vs. server. We do have a custom TestSuite class though that finds and runs the tests based on this information, as it was easier and less error prone than manually maintaining which tests to run.
In our case we use Spring remoting to talk to servlets and EJB's (via the servlets), and testing both cases is simply a separate launch configuration within Eclipse.
We used JunitEE a few years ago, but eventually gave up on it in favor of just using JUnit throughout. This enabled us to have developers do all their testing without a server at all and run both unit and what I would call low level integration tests in their IDE. Then we let the build machine run the same integration tests against the same code now deployed in the actual server. This makes the development cycle much faster as we rarely need to run the server and deploy service code.
JUnit(EE) is what every major project($100mil+) I've supported has used. It's really a fantastic tool and knowing how to use it is invaluable when/if you decide to look for other job opportunities.
I supported a government financial system that used no unit testing but after a lot of pushing we finally implemented JUnit. The system I work on now is a large government agency modernization and we use JUnit for all of our unit testing. The two large firms supporting the modernization have essential made JUnit the standard across all of the sub projects. We've got ~200 developers using it without a hitch.
It's quick and easy to set up and once you understand it and you can leverage the features it will demonstrate how invaluable it is.