You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Ken Weiner <kw...@gmail.com> on 2005/10/04 03:10:53 UTC
writing cactus tests for MyFaces
Hello, I've been asked to write some cactus tests for
http://issues.apache.org/jira/browse/MYFACES-622 before my patch is applied.
I am familiar with JUnit and even JWebUnit, but new to Cactus. It would help
me if someone could provide some tips on getting started with writing a
Cactus test for MyFaces. I see that there is one called
HtmlDateRenderCactus, but I'm not sure what I need to setup before I try to
invoke it.
Thanks,
Ken
Re: writing cactus tests for MyFaces
Posted by Bill Dudney <bd...@mac.com>.
Hi Ken,
As you describe is a fine way to do things in terms of getting your
cactus tests running. I prefer to start tomcat in 'debug' mode with
catalina.sh jpda start then remotely attach to it instead of using
Sysdeo. I add a file called cactus.properties containing the
cactus.contextURL property to my bin or classes directory (where
eclipse is putting its output). You can then use 'run Junit test'
just as you describe but you won't have to worry about tomcat
consuming all available memory in your Eclipse environment :-) But
your way works just fine too.
The stack trace is probably expected as I've not done much to the
HtmlDateRendererCactus test since I started working on bugs 623 & 628.
TTFN,
bd-
On Oct 4, 2005, at 2:09 PM, Ken Weiner wrote:
> Thanks for the pointers. I was able to run the cactus tests for
> tomahawk by doing the following:
>
> I'm using Eclipse 3.1 with the Tomcat Sysdeo plugin and Tomcat 5.5.9
>
> 1) Run "ant build-cactus-war" from within tomahawk/build
> 2) Copy the resulting tomahawk/build/cactus-app.war to the webapps
> directory of Tomcat
> 3) Add "-Dcactus.contextURL=http://localhost:8080/cactus-app" as a
> VM argument in Eclipse
> 4) Start Tomcat via the Sysdeo plugin
> 5) Right-click on a cactus test within the tomahawk project and
> choose "Run JUnit Test"
>
> Is this generally what people are doing? Is the design that there
> are seperate cactus-app.war files produced for each module (impl,
> tomahawk, etc) so you can only run one group of tests at a time?
> Should I have used the ant tasks: "ant cactus-test" or "ant cactus-
> test-all"?
>
> By the way, I ran the only cactus test that I found in tomahawk and
> the test didn't pass. I got the following stack trace:
>
> junit.framework.ComparisonFailure: expected:<...> but was:<0...>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at
> org.apache.myfaces.custom.date.HtmlDateRenderCactus.testDecodeDisabled
> (HtmlDateRenderCactus.java:168)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at
> org.apache.cactus.internal.AbstractCactusTestCase.runBareServer
> (AbstractCactusTestCase.java:153)
> at
> org.apache.cactus.internal.server.AbstractWebTestCaller.doTest
> (AbstractWebTestCaller.java:119)
> at
> org.apache.cactus.internal.server.AbstractWebTestController.handleRequ
> est_aroundBody0(AbstractWebTestController.java:93)
> at
> org.apache.cactus.internal.server.AbstractWebTestController.handleRequ
> est_aroundBody1$advice(AbstractWebTestController.java:224)
> at
> org.apache.cactus.internal.server.AbstractWebTestController.handleRequ
> est(AbstractWebTestController.java)
> at
> org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2
> (ServletTestRedirector.java:101)
> at
> org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3
> $advice(ServletTestRedirector.java:224)
> at org.apache.cactus.server.ServletTestRedirector.doPost
> (ServletTestRedirector.java)
> at
> org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0
> (ServletTestRedirector.java:72)
> at
> org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1
> $advice(ServletTestRedirector.java:224)
> at org.apache.cactus.server.ServletTestRedirector.doGet
> (ServletTestRedirector.java)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
> (ApplicationFilterChain.java:252)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter
> (ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke
> (StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke
> (StandardContextValve.java:178)
> at org.apache.catalina.core.StandardHostValve.invoke
> (StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke
> (ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke
> (StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service
> (CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process
> (Http11Processor.java:856)
> at org.apache.coyote.http11.Http11Protocol
> $Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
> (PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
> (LeaderFollowerWorkerThread.java:80)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
> (ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
>
>
>
> On 10/4/05, Bill Dudney <bd...@mac.com> wrote:
> Hi Ken,
>
> Thanks for writing tests!
>
> OK - first if you know JUnit you know about 80% of what you need to
> know to write cactus tests so you are at a good starting point.
>
> In cactus you have the same testXXX methods that you have in JUnit.
> However the actual test is run on the server. The 'how it works'
> page here;
>
> http://jakarta.apache.org/cactus/how_it_works.html
>
> does a great job of explaining the basics of how cactus works
> compared to JUnit.
>
> While writing tests for MyFaces components you should subclass from
> ServletTestCase and create your tests. Keep in mind that the
> beginXXX and endXXX execute on the client side as a way for you to
> setup the request (i.e. beginXXX) and then assert the look of the
> returned HTML (i.e. endXXX). As an example there is a
> LifecycleImplCactus test that implements beginXXX to simulate a JSP
> request to the faces servlet, then the test uses that to setup the
> correct environment, runs the test and asserts the correct stuff
> happened in the lifecycle (through a test only impl of the
> PhaseListener interface).
>
> So for a component test you can do something like this
>
> public void beginEncodeEnd(WebRequest request) {
> request.addParameter("form1:number1", " 100.4");
> request.setURL("localhost:8080", "/test-app", "/faces", "/
> index.jsp", null);
> }
>
> public void testExecute() throws Exception {
> // setup a component to test
> UIViewRoot root = facesContext.getViewRoot();
> UIForm form = new UIForm();
> form.setId("form1");
> root.addForm(new UIForm()); // needs more detail but
> hopefully you get the idea
> MYComponent comp = new MYComponent();
> comp.setId("number1");
> form.addChild(comp);
> // simulate that this is the 2nd request for this page
> // so that we will go through all 6 phases
> // this will cause the viewRoot to be serialized for the
> service method
> // below to find
> StateManager stateManager = facesContext.getApplication()
> .getStateManager();
> stateManager.saveSerializedView(facesContext);
> // this will push the impl through all 6 phases
> servlet.service(this.request, this.response);
> }
>
> public void endEncodeEnd(WebResponse response) throws Exception {
> HTMLElement element = response.getElementWithID
> ("form1:number1");
> assertEquals(" 100.4", element.getText());
> }
>
>
> Then in your setUp method;
>
> protected void setUp() throws Exception {
> super.setUp();
> servlet = new FacesServlet();
> servlet.init(this.config);
> // create a facesContext so you can simulate the first request
> FacesContextFactory facesContextFactory =
> (FacesContextFactory) FactoryFinder
> .getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
> facesContext = facesContextFactory.getFacesContext(this.config
> .getServletContext(), request, response, lifecycle);
> }
>
> HTH,
>
> I'll try to get the meat of this posted to the wiki soon.
>
> Also this is pseudo code off the top of my head, don't expect it to
> work copy/paste
>
> You can see an example in the LifecycleImplCactus on the 1.1.1 branch.
>
> TTFN,
>
> -bd-
>
> On Oct 3, 2005, at 7:10 PM, Ken Weiner wrote:
>
>> Hello, I've been asked to write some cactus tests for http://
>> issues.apache.org/jira/browse/MYFACES-622 before my patch is applied.
>>
>> I am familiar with JUnit and even JWebUnit, but new to Cactus. It
>> would help me if someone could provide some tips on getting
>> started with writing a Cactus test for MyFaces. I see that there
>> is one called HtmlDateRenderCactus, but I'm not sure what I need
>> to setup before I try to invoke it.
>>
>> Thanks,
>>
>> Ken
>
>
Re: writing cactus tests for MyFaces
Posted by Ken Weiner <kw...@gmail.com>.
Thanks for the pointers. I was able to run the cactus tests for tomahawk by
doing the following:
I'm using Eclipse 3.1 with the Tomcat Sysdeo plugin and Tomcat 5.5.9
1) Run "ant build-cactus-war" from within tomahawk/build
2) Copy the resulting tomahawk/build/cactus-app.war to the webapps directory
of Tomcat
3) Add "-Dcactus.contextURL=http://localhost:8080/cactus-app" as a VM
argument in Eclipse
4) Start Tomcat via the Sysdeo plugin
5) Right-click on a cactus test within the tomahawk project and choose "Run
JUnit Test"
Is this generally what people are doing? Is the design that there are
seperate cactus-app.war files produced for each module (impl, tomahawk, etc)
so you can only run one group of tests at a time? Should I have used the ant
tasks: "ant cactus-test" or "ant cactus-test-all"?
By the way, I ran the only cactus test that I found in tomahawk and the test
didn't pass. I got the following stack trace:
junit.framework.ComparisonFailure: expected:<...> but was:<0...>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at org.apache.myfaces.custom.date.HtmlDateRenderCactus.testDecodeDisabled(
HtmlDateRenderCactus.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at org.apache.cactus.internal.AbstractCactusTestCase.runBareServer(
AbstractCactusTestCase.java:153)
at org.apache.cactus.internal.server.AbstractWebTestCaller.doTest(
AbstractWebTestCaller.java:119)
at
org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody0
(AbstractWebTestController.java:93)
at
org.apache.cactus.internal.server.AbstractWebTestController.handleRequest_aroundBody1$advice
(AbstractWebTestController.java:224)
at org.apache.cactus.internal.server.AbstractWebTestController.handleRequest
(AbstractWebTestController.java)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2(
ServletTestRedirector.java:101)
at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3$advice(
ServletTestRedirector.java:224)
at org.apache.cactus.server.ServletTestRedirector.doPost(
ServletTestRedirector.java)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(
ServletTestRedirector.java:72)
at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$advice(
ServletTestRedirector.java:224)
at org.apache.cactus.server.ServletTestRedirector.doGet(
ServletTestRedirector.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:105)
at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:856)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection
(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
On 10/4/05, Bill Dudney <bd...@mac.com> wrote:
>
> Hi Ken,
> Thanks for writing tests!
>
> OK - first if you know JUnit you know about 80% of what you need to know
> to write cactus tests so you are at a good starting point.
>
> In cactus you have the same testXXX methods that you have in JUnit.
> However the actual test is run on the server. The 'how it works' page here;
>
> http://jakarta.apache.org/cactus/how_it_works.html
>
> does a great job of explaining the basics of how cactus works compared to
> JUnit.
>
> While writing tests for MyFaces components you should subclass from
> ServletTestCase and create your tests. Keep in mind that the beginXXX and
> endXXX execute on the client side as a way for you to setup the request (
> i.e. beginXXX) and then assert the look of the returned HTML (i.e.
> endXXX). As an example there is a LifecycleImplCactus test that implements
> beginXXX to simulate a JSP request to the faces servlet, then the test uses
> that to setup the correct environment, runs the test and asserts the correct
> stuff happened in the lifecycle (through a test only impl of the
> PhaseListener interface).
>
> So for a component test you can do something like this
>
> public void beginEncodeEnd(WebRequest request) {
> request.addParameter("form1:number1", "100.4");
> request.setURL("localhost:8080", "/test-app", "/faces", "/index.jsp",
> null);
> }
>
> public void testExecute() throws Exception {
> // setup a component to test
> UIViewRoot root = facesContext.getViewRoot();
> UIForm form = new UIForm();
> form.setId("form1");
> root.addForm(new UIForm()); // needs more detail but hopefully you get the
> idea
> MYComponent comp = new MYComponent();
> comp.setId("number1");
> form.addChild(comp);
> // simulate that this is the 2nd request for this page
> // so that we will go through all 6 phases
> // this will cause the viewRoot to be serialized for the service method
> // below to find
> StateManager stateManager = facesContext.getApplication()
> .getStateManager();
> stateManager.saveSerializedView(facesContext);
> // this will push the impl through all 6 phases
> servlet.service(this.request, this.response);
> }
>
> public void endEncodeEnd(WebResponse response) throws Exception {
> HTMLElement element = response.getElementWithID("form1:number1");
> assertEquals("100.4", element.getText());
> }
>
>
> Then in your setUp method;
>
> protected void setUp() throws Exception {
> super.setUp();
> servlet = new FacesServlet();
> servlet.init(this.config);
> // create a facesContext so you can simulate the first request
> FacesContextFactory facesContextFactory = (FacesContextFactory)
> FactoryFinder
> .getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
> facesContext = facesContextFactory.getFacesContext(this.config
> .getServletContext(), request, response, lifecycle);
> }
>
> HTH,
>
> I'll try to get the meat of this posted to the wiki soon.
>
> Also this is pseudo code off the top of my head, don't expect it to work
> copy/paste
>
> You can see an example in the LifecycleImplCactus on the 1.1.1 branch.
>
> TTFN,
>
> -bd-
>
> On Oct 3, 2005, at 7:10 PM, Ken Weiner wrote:
>
> Hello, I've been asked to write some cactus tests for
> http://issues.apache.org/jira/browse/MYFACES-622 before my patch is
> applied.
>
> I am familiar with JUnit and even JWebUnit, but new to Cactus. It would
> help me if someone could provide some tips on getting started with writing a
> Cactus test for MyFaces. I see that there is one called
> HtmlDateRenderCactus, but I'm not sure what I need to setup before I try to
> invoke it.
>
> Thanks,
>
> Ken
>
>
>
Re: writing cactus tests for MyFaces
Posted by Ken Weiner <kw...@gmail.com>.
Bill,
Thanks for the help. I submitted
*MYFACES-664<http://issues.apache.org/jira/browse/MYFACES-664>
* which includes an attached cactus test for HtmlSelectManyCheckbox
rendering. I added the endXXX methods, but didn't see the need to call
facesServlet.service. I'm probably not doing it the right way so feel free
to correct it. The tests do pass though...
-Ken
On 10/4/05, Bill Dudney <bd...@mac.com> wrote:
>
> Well since you are in cactus you don't need mocks.
> you can in your endXXX method assert that the proper text is returned.
>
> in the textXXX add a form top the view root, and an instance of
> HtmlSelectManyCheckbox (properly configured) to the form then call
> facesServlet.service
>
> in your endXXX method you should have HTML rendered.
>
> TTFN,
>
> -bd-
>
Re: writing cactus tests for MyFaces
Posted by Bill Dudney <bd...@mac.com>.
Well since you are in cactus you don't need mocks.
you can in your endXXX method assert that the proper text is returned.
in the textXXX add a form top the view root, and an instance of
HtmlSelectManyCheckbox (properly configured) to the form then call
facesServlet.service
in your endXXX method you should have HTML rendered.
TTFN,
-bd-
On Oct 4, 2005, at 3:28 PM, Ken Weiner wrote:
> The test I'm trying to write is going to setup the
> HtmlSelectManyCheckbox component, call encodeBegin(), encodeEnd()
> on it and then assert that the componenet generated the correct
> markup. My understanding is that the component will write to a
> javax.faces.context.ResponseWriter that it gets from the
> FacesContext. Therefore, I need to stuff a MockResponseWriter into
> the FacesContext before asking the component to render. Is there
> already a mock ResponseWriter written for testing purposes? Is
> there another way I should be doing things?
>
> Thanks, Ken
>
> On 10/4/05, Bill Dudney <bd...@mac.com> wrote:
> Hi Ken,
>
> Thanks for writing tests!
>
> OK - first if you know JUnit you know about 80% of what you need to
> know to write cactus tests so you are at a good starting point.
>
> In cactus you have the same testXXX methods that you have in JUnit.
> However the actual test is run on the server. The 'how it works'
> page here;
>
> http://jakarta.apache.org/cactus/how_it_works.html
>
> does a great job of explaining the basics of how cactus works
> compared to JUnit.
>
> While writing tests for MyFaces components you should subclass from
> ServletTestCase and create your tests. Keep in mind that the
> beginXXX and endXXX execute on the client side as a way for you to
> setup the request (i.e. beginXXX) and then assert the look of the
> returned HTML (i.e. endXXX). As an example there is a
> LifecycleImplCactus test that implements beginXXX to simulate a JSP
> request to the faces servlet, then the test uses that to setup the
> correct environment, runs the test and asserts the correct stuff
> happened in the lifecycle (through a test only impl of the
> PhaseListener interface).
>
> So for a component test you can do something like this
>
> public void beginEncodeEnd(WebRequest request) {
> request.addParameter("form1:number1", " 100.4");
> request.setURL("localhost:8080", "/test-app", "/faces", "/
> index.jsp", null);
> }
>
> public void testExecute() throws Exception {
> // setup a component to test
> UIViewRoot root = facesContext.getViewRoot();
> UIForm form = new UIForm();
> form.setId("form1");
> root.addForm(new UIForm()); // needs more detail but
> hopefully you get the idea
> MYComponent comp = new MYComponent();
> comp.setId("number1");
> form.addChild(comp);
> // simulate that this is the 2nd request for this page
> // so that we will go through all 6 phases
> // this will cause the viewRoot to be serialized for the
> service method
> // below to find
> StateManager stateManager = facesContext.getApplication()
> .getStateManager();
> stateManager.saveSerializedView(facesContext);
> // this will push the impl through all 6 phases
> servlet.service(this.request, this.response);
> }
>
> public void endEncodeEnd(WebResponse response) throws Exception {
> HTMLElement element = response.getElementWithID
> ("form1:number1");
> assertEquals(" 100.4", element.getText());
> }
>
>
> Then in your setUp method;
>
> protected void setUp() throws Exception {
> super.setUp();
> servlet = new FacesServlet();
> servlet.init(this.config);
> // create a facesContext so you can simulate the first request
> FacesContextFactory facesContextFactory =
> (FacesContextFactory) FactoryFinder
> .getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
> facesContext = facesContextFactory.getFacesContext(this.config
> .getServletContext(), request, response, lifecycle);
> }
>
> HTH,
>
> I'll try to get the meat of this posted to the wiki soon.
>
> Also this is pseudo code off the top of my head, don't expect it to
> work copy/paste
>
> You can see an example in the LifecycleImplCactus on the 1.1.1 branch.
>
> TTFN,
>
> -bd-
>
> On Oct 3, 2005, at 7:10 PM, Ken Weiner wrote:
>
>> Hello, I've been asked to write some cactus tests for http://
>> issues.apache.org/jira/browse/MYFACES-622 before my patch is applied.
>>
>> I am familiar with JUnit and even JWebUnit, but new to Cactus. It
>> would help me if someone could provide some tips on getting
>> started with writing a Cactus test for MyFaces. I see that there
>> is one called HtmlDateRenderCactus, but I'm not sure what I need
>> to setup before I try to invoke it.
>>
>> Thanks,
>>
>> Ken
>
>
Re: writing cactus tests for MyFaces
Posted by Ken Weiner <kw...@gmail.com>.
The test I'm trying to write is going to setup the HtmlSelectManyCheckbox
component, call encodeBegin(), encodeEnd() on it and then assert that the
componenet generated the correct markup. My understanding is that the
component will write to a javax.faces.context.ResponseWriter that it gets
from the FacesContext. Therefore, I need to stuff a MockResponseWriter into
the FacesContext before asking the component to render. Is there already a
mock ResponseWriter written for testing purposes? Is there another way I
should be doing things?
Thanks, Ken
On 10/4/05, Bill Dudney <bd...@mac.com> wrote:
>
> Hi Ken,
> Thanks for writing tests!
>
> OK - first if you know JUnit you know about 80% of what you need to know
> to write cactus tests so you are at a good starting point.
>
> In cactus you have the same testXXX methods that you have in JUnit.
> However the actual test is run on the server. The 'how it works' page here;
>
> http://jakarta.apache.org/cactus/how_it_works.html
>
> does a great job of explaining the basics of how cactus works compared to
> JUnit.
>
> While writing tests for MyFaces components you should subclass from
> ServletTestCase and create your tests. Keep in mind that the beginXXX and
> endXXX execute on the client side as a way for you to setup the request (
> i.e. beginXXX) and then assert the look of the returned HTML (i.e.
> endXXX). As an example there is a LifecycleImplCactus test that implements
> beginXXX to simulate a JSP request to the faces servlet, then the test uses
> that to setup the correct environment, runs the test and asserts the correct
> stuff happened in the lifecycle (through a test only impl of the
> PhaseListener interface).
>
> So for a component test you can do something like this
>
> public void beginEncodeEnd(WebRequest request) {
> request.addParameter("form1:number1", "100.4");
> request.setURL("localhost:8080", "/test-app", "/faces", "/index.jsp",
> null);
> }
>
> public void testExecute() throws Exception {
> // setup a component to test
> UIViewRoot root = facesContext.getViewRoot();
> UIForm form = new UIForm();
> form.setId("form1");
> root.addForm(new UIForm()); // needs more detail but hopefully you get the
> idea
> MYComponent comp = new MYComponent();
> comp.setId("number1");
> form.addChild(comp);
> // simulate that this is the 2nd request for this page
> // so that we will go through all 6 phases
> // this will cause the viewRoot to be serialized for the service method
> // below to find
> StateManager stateManager = facesContext.getApplication()
> .getStateManager();
> stateManager.saveSerializedView(facesContext);
> // this will push the impl through all 6 phases
> servlet.service(this.request, this.response);
> }
>
> public void endEncodeEnd(WebResponse response) throws Exception {
> HTMLElement element = response.getElementWithID("form1:number1");
> assertEquals("100.4", element.getText());
> }
>
>
> Then in your setUp method;
>
> protected void setUp() throws Exception {
> super.setUp();
> servlet = new FacesServlet();
> servlet.init(this.config);
> // create a facesContext so you can simulate the first request
> FacesContextFactory facesContextFactory = (FacesContextFactory)
> FactoryFinder
> .getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
> facesContext = facesContextFactory.getFacesContext(this.config
> .getServletContext(), request, response, lifecycle);
> }
>
> HTH,
>
> I'll try to get the meat of this posted to the wiki soon.
>
> Also this is pseudo code off the top of my head, don't expect it to work
> copy/paste
>
> You can see an example in the LifecycleImplCactus on the 1.1.1 branch.
>
> TTFN,
>
> -bd-
>
> On Oct 3, 2005, at 7:10 PM, Ken Weiner wrote:
>
> Hello, I've been asked to write some cactus tests for
> http://issues.apache.org/jira/browse/MYFACES-622 before my patch is
> applied.
>
> I am familiar with JUnit and even JWebUnit, but new to Cactus. It would
> help me if someone could provide some tips on getting started with writing a
> Cactus test for MyFaces. I see that there is one called
> HtmlDateRenderCactus, but I'm not sure what I need to setup before I try to
> invoke it.
>
> Thanks,
>
> Ken
>
>
>
Re: writing cactus tests for MyFaces
Posted by Bill Dudney <bd...@mac.com>.
Hi Ken,
Thanks for writing tests!
OK - first if you know JUnit you know about 80% of what you need to
know to write cactus tests so you are at a good starting point.
In cactus you have the same testXXX methods that you have in JUnit.
However the actual test is run on the server. The 'how it works' page
here;
http://jakarta.apache.org/cactus/how_it_works.html
does a great job of explaining the basics of how cactus works
compared to JUnit.
While writing tests for MyFaces components you should subclass from
ServletTestCase and create your tests. Keep in mind that the beginXXX
and endXXX execute on the client side as a way for you to setup the
request (i.e. beginXXX) and then assert the look of the returned HTML
(i.e. endXXX). As an example there is a LifecycleImplCactus test that
implements beginXXX to simulate a JSP request to the faces servlet,
then the test uses that to setup the correct environment, runs the
test and asserts the correct stuff happened in the lifecycle (through
a test only impl of the PhaseListener interface).
So for a component test you can do something like this
public void beginEncodeEnd(WebRequest request) {
request.addParameter("form1:number1", "100.4");
request.setURL("localhost:8080", "/test-app", "/faces", "/
index.jsp", null);
}
public void testExecute() throws Exception {
// setup a component to test
UIViewRoot root = facesContext.getViewRoot();
UIForm form = new UIForm();
form.setId("form1");
root.addForm(new UIForm()); // needs more detail but
hopefully you get the idea
MYComponent comp = new MYComponent();
comp.setId("number1");
form.addChild(comp);
// simulate that this is the 2nd request for this page
// so that we will go through all 6 phases
// this will cause the viewRoot to be serialized for the
service method
// below to find
StateManager stateManager = facesContext.getApplication()
.getStateManager();
stateManager.saveSerializedView(facesContext);
// this will push the impl through all 6 phases
servlet.service(this.request, this.response);
}
public void endEncodeEnd(WebResponse response) throws Exception {
HTMLElement element = response.getElementWithID
("form1:number1");
assertEquals("100.4", element.getText());
}
Then in your setUp method;
protected void setUp() throws Exception {
super.setUp();
servlet = new FacesServlet();
servlet.init(this.config);
// create a facesContext so you can simulate the first request
FacesContextFactory facesContextFactory =
(FacesContextFactory) FactoryFinder
.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
facesContext = facesContextFactory.getFacesContext(this.config
.getServletContext(), request, response, lifecycle);
}
HTH,
I'll try to get the meat of this posted to the wiki soon.
Also this is pseudo code off the top of my head, don't expect it to
work copy/paste
You can see an example in the LifecycleImplCactus on the 1.1.1 branch.
TTFN,
-bd-
On Oct 3, 2005, at 7:10 PM, Ken Weiner wrote:
> Hello, I've been asked to write some cactus tests for http://
> issues.apache.org/jira/browse/MYFACES-622 before my patch is applied.
>
> I am familiar with JUnit and even JWebUnit, but new to Cactus. It
> would help me if someone could provide some tips on getting started
> with writing a Cactus test for MyFaces. I see that there is one
> called HtmlDateRenderCactus, but I'm not sure what I need to setup
> before I try to invoke it.
>
> Thanks,
>
> Ken
Re: writing cactus tests for MyFaces
Posted by Sean Schofield <se...@gmail.com>.
Bill had a nice write up on this a few days ago ...
http://www.mail-archive.com/dev%40myfaces.apache.org/msg05900.html
sean
On 10/3/05, Ken Weiner <kw...@gmail.com> wrote:
> Hello, I've been asked to write some cactus tests for
> http://issues.apache.org/jira/browse/MYFACES-622 before my
> patch is applied.
>
> I am familiar with JUnit and even JWebUnit, but new to Cactus. It would
> help me if someone could provide some tips on getting started with writing a
> Cactus test for MyFaces. I see that there is one called
> HtmlDateRenderCactus, but I'm not sure what I need to setup before I try to
> invoke it.
>
> Thanks,
>
> Ken
>