Hello I've been googling a lot about this.
I want to test my JSf application without deploying it in to Server, so basically i want perform mock test like test.
I've used JSFUnit before. If its possible with JSFUnit itself, HOW to DO THAT?
Is there any other JSF 2.0 testing framework which is simple to use and can simulate container for running tests without container ?
[Along with names please provide some tutorial or example references also]
Please help!!
You could check out the Arquillian Project
You cand find a 1h video tutorial on Testing JSF Applications with Arquillian and Selenium here
Updated Feb 2018: OpenBrace Limited has closed down, and its ObMimic product is no longer supported.
Although not specifically designed for JSF testing, the ObMimic library of Servlet API test-doubles might be suitable.
It provides plain-Java, out-of-container simulations of Servlet API objects that are accurate enough and configurable enough to be able to run the JSF servlet. This lets you test complete GETs and POSTs of JSF pages without needing to deploy to a server or use a container.
Your tests can create and configure whatever Servlet API objects are necessary for each test (including a ServletContext with any necessary resources, mappings etc), use these to initialise and invoke the JSF servlet to process a request, and then examine the results. Your tests can also install JSF PhaseListeners to access the FacesContext and examine any relevant JSF data structures at appropriate points during the JSF processing.
The ObMimic website and documentation includes a "How to Test JSF Pages" guide that goes into this in some detail, including example code.
Note that as well as testing "real" JSF pages, you can also use this approach with test-specific JSF pages that just invoke or trigger whatever JSF code you are trying to test (i.e. each test can install any desired JSF page text into the ServletContext and then use the JSF servlet to run it).
Related
I have to convert a WebSphere portal application to a standard web application which can be deployed to WebSphere itself for now (and to JBoss later).
How can I find what built-in portal features are being used?
I have full code access. Are there any tools for this? What are the things I should consider?
Depends on how the application has been developed and which version of the portlet spec your application was built against.
If we take the case of porting a single portlet to a standard J2EE where the latest portlet spec is used the application might be using more modern practices e.g. be using resourceURLs and Ajax calls from JS to communicate with the backend.
This is the best case scenario, where you can take the JSP remove the portlet specific stuff e.g. the context roots and portlet name spaces. Then convert your resourceURLs into servlets by creating servlets which either call the same service methods or depending on how the code was written taken the code straight for the serveResource methods in the Portlet class.
Now worst case scenario for porting, this is where the portlet makes heavy use of actionURLs and other portal features which are very specific to the portlet spec. I'd guess that the best way of going about porting these is to try emulate the behavior of the portlet. You could try to hold all of your state information on the backend like a portlet does and replace these actionURLs/renderURLs with JSPs/servlets appropriately while having some object on the backend which stores the current state of the page for each user.
Hope this helps, more information on your project would obviously make it easier to help.
In regards to finding out what portlet specific features have been used look at the portlet class' imports and the tags used in the JSP along with the portlet.xml
I am a new web developer who is struggling to even set up local development environment with Eclipse. My goal is to eventually put my idea into a cool website that could be hosted on 64MB private JVM Tomcat 6 server (here).
I tried everything I could last 4 days reading bunch of tutorial sites and came up with an Eclipse project which could be downloaded. download.
I am overwhelmed with integrating so many frameworks (I wasn't an open source guy before), I feel that I'm stuck. Following are some questions I have.
How come when I run above project on Tomcat 6 server on local machine, I have to access it with "http://localhost/richfaces-tomcat6/" I want to be able to access it with "http://localhost/Namo/". Because "Namo" is going to be my website name.
How come "http://localhost/richfaces-tomcat6/index.xhtml" is not showing the inputText at all?
How come I cannot use "#Named" annotation for the managed beans? Instead I have to use "#ManagedBean". I read some where that #ManagedBean is really for the legacy system. Does this matter?
I am trying to code in JSF 2 with a bit of Ajax features on the site. I read some where Richfaces is useful. Am I even on the right track with setting these up?
I know I am asking a lot of questions. I am so ready to have something set up locally and hit the books for JSF but I can't even get started on it which is very frustrating. I would really appreciate it if somebody could help me or guide me to right direction.
How come when I run above project on Tomcat 6 server on local machine, I have to access it with "http://localhost/richfaces-tomcat6/" I want to be able to access it with "http://localhost/Namo/". Because "Namo" is going to be my website name.
The context path defaults to the Eclipse project name. You should have edited the context path in one of the last steps of the Eclipse project creation wizard. You can always edit it afterwards in the Web Project Settings section of the project's properties (rightclick project and choose Properties).
How come "http://localhost/richfaces-tomcat6/index.xhtml" is not showing the inputText at all?
Apparenty the request URL did not match the URL pattern of the FacesServlet as definied in web.xml. The given URL expects it to be mapped on an <url-pattern> of *.xhtml. Eclipse defaults to /faces/* and/or *.jsf and would require you to open the page by either http://localhost/richfaces-tomcat6/faces/index.xhtml or http://localhost/richfaces-tomcat6/index.jsf. But mapping the FacesServlet on *.xhtml is much better.
How come I cannot use "#Named" annotation for the managed beans? Instead I have to use "#ManagedBean". I read some where that #ManagedBean is really for the legacy system. Does this matter?
The #Named annotation is part of CDI which is part of Java EE 6. Tomcat is however a simple JSP/Servlet container and not a full fledged Java EE container. You'd either need to install CDI yourself if you want to use it on Tomcat, or to replace Tomcat by a fuller fledged Java EE container, such as Glassfish 3 or JBoss AS. See also the Weld documentation (Weld is the codename of the CDI reference implementation). Note that you don't necessarily need CDI to get JSF to run. Using #ManagedBean ought to be sufficient for a simple web application.
I am trying to code in JSF 2 with a bit of Ajax features on the site. I read some where Richfaces is useful. Am I even on the right track with setting these up?
JSF2 already supports Ajax out the box with the <f:ajax> tag. RichFaces is just a component library which offers more enhanced components and skinnability support on top of the standard component set. See also Communication in JSF 2.0.
1, 2 JSF 2.0 tutorial with eclipse tomcat
3 #ManagedBean makes sense for applications that use JSF but do not use JSR 299
4 yes you can do some cool stuff using RF, also jsf 2.0 has support of <f:ajax> so without RF using default implementation you could also do the AJAX stuff
You have severe memory constraints, so I'd better recommend to look at lightweight templating engines like Velocity or Freemarker for your pages and MVC frameworks like Struts/Struts 2 or Spring MVC.
I'm interested in porting an existing application which was written using Spring/Struts2/Hibernate to GAE. I didn't read many successful stories about that so first of all I'm wondering if it is wise to use any of them there. I want to get rid of hibernate and to use the google data store instead since it's obvious hibernate is not a good choice on GAE. So my main questions refers to Struts2(webworks)/Spring. My app uses simple JSP pages, no other template mechanism.
My question refers to the following aspects:
Currently each page has struts actions associated. Each request is taken by struts dispatcher an then it is dispatched to specific action class after which it invokes a specific jsp, according to the config file.
Everything is instantiated by Spring(actions, factories, hibernate layers,...)
The security is managed through a Spring Security(former acegi).
My first impression is that I should get rid of Spring because GAE should manage all the objects in order to work in a distributed environment. I have a few antagonistic thoughts regarding Struts. However, if I get rid of them ,I'm not sure if I should do it and in case I will, what to choose instead. Is GAE good enough to provide all the things I needed? I assume instantiation should be handled by GAE to have a truly sclalable solution. What about session management, security & user privileges? GAE provides good mechanism to manage them behind the scene or I should manually handle them like in a classic jsp solution? Will I end in having a huge web.xml?
Are there any frameworks that fits well in GAE and which can replace Spring/Struts? I would be interested to find out from someone who experienced those problems in GAE.
Here is a list of frameworks which are known to work or to have issues:
http://code.google.com/p/googleappengine/wiki/WillItPlayInJava
In general Hibernate will not work, but you could potentially use Java Persistence instead. Struts should be OK, but Spring Security is not fully compatible while other Spring parts are fine.
As far as I know, Struts is generally a layer over standard Servlet API - so it should be running without many changes. Spring also is not a problem, in fact, on the web there are many blog entries about spring on GAE. Hibernate - yeah, better use JPA.
If you want to rewrite whole app, you can always go with GWT, even with Spring ( GWT/GAE Spring IoC powered )
I'm building a JS client and want to be able to quickly test stuff locally during development. I need a mocked server for that.
Since I'm using Maven and its Jetty plugin, I easily got a servlet up that sends responses. Now I would like to slightly improve on this by adding JSP for the view.
I'm already familiar with Struts (and Wicket), but since JSP and Servlet support is already built into Jetty, I thought I could just throw some servlets and some JSPs in there, connecting them with configuration (in the web.xml?) without resorting to a major framework.
Googling so far brings me only general architecture and specification stuff or Struts examples.
JSPs are servlets. So everything you do in a servlet can be done in a JSP directly (or nearly everything).
It's however a bad practice to put Java code into JSPs. So you might just use servlets for the controller logic, and then use request.getRequestDispatcher("/somePage.jsp").forward(request, response) to dispatch the request and response to the JSP. That's the absolute minimum an MVC framework does.
More explanation of servlet basics, inclusing some example code and further links on the wiki page for the servlets tag.
It's unclear what you expect from your minimal framework. But using a framework like Stripes, for example, is pretty straightforward and does all this for you, by adding some lines in the web.xml and some annotations in Action classes replacing the servlets as controllers.
Can you separate components of an IceFaces application so they can be tested in isolation instead of using something like Selenium or HttpUnit on the assembled application?
Backing beans can be easily isolated (if written to be testable) but I am interested in testing the template/display parts of the application while using as little of the rest of the application as possible. Can this be done? How?
Is there a way to render an IceFaces object as text using "dummy data" that I can then run through traditional unit tests?
I can think of ways to do all of this, but they involve creating multiple applications (one for each component I wish to test). However, this seems like a sub-optimal way of doing things.
If I understand your question correctly, then it ought to be a simple matter of creating special dummy backing beans for your pages, and then creating a test JSF configuration file mapping those beans to the .jspx files. The dummy beans, of course, won't touch any business logic or back-end services -- they'll simply be simple sets of data that will be easy to verify in your tests.
Create an ant script to substitute in your dummy backing beans and the test config file. Run your tests. If you don't want something as heavy as HTTPUnit, and if you're using Spring in your app, look at this blog post for an excellent way to mock up a full web context without a web server. Your tests will probably need to sniff the raw HTML output to verify the results. This is going to be tricky, because IceFaces loves to munge DIV IDs and other relevant parts of the DOM tree that you may want to sniff for. (This alone may be the reason why very few JSF developers try to unit test JSF output.)
Once your tests are verified, swap the regular beans and config file back into the app.
Voila! You've just unit-tested your JSF components.
Mind you, the whole business of swapping out beans and config files is messy. It would be much, much easier if IceFaces used Spring to match backing beans to JSF pages -- then you could simply define the test-beans in an application.xml with the relevant test classes. But such is life.
Good luck, and let me know how it works out for you!
This is not what exactly what you are asking for but JSFUnit (which uses JUnit, Cactus, HtmlUnit, and HttpUnit) seems to be a serious candidate for testing in the JSF land. Did you consider this option? Maybe have a look at the JSFUnit Wiki and its Getting Started Guide.
Please note that the FAQ is reporting some problems with IceFaces but its pretty old (early 2009) and the situation might have changed since then (there are some demo projects like jboss-jsfunit-examples-icefaces or icefaces-demo-address in JBoss repository so it may be worth to ask the exact status either on JSFUnit or IceFaces mailing lists).
EDIT: As mentioned in a comment, the OP is looking for something less "high level". Maybe have a look at the Shale Test Framework:
The Shale Test Framework provides mock
object libraries, plus base classes
for creating your own JUnit TestCases.
Mock objects are provided in package
org.apache.shale.test.mock for the
following container APIs:
JavaServer Faces
Servlet
Disclaimer: Apache Shale moved into the Attic in May 2009 (i.e. it has reached its end of life) but I don't know any other "mature" mock framework for JSF so I'm mentioning it anyway (the code is still there). I'll follow this thread with a very high interest for other solutions :)