[
https://issues.apache.org/jira/browse/MYFACES-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3376.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.1.4
2.0.10
> Create abstract test classes that runs MyFaces Core as in a container
> ---------------------------------------------------------------------
>
> Key: MYFACES-3376
> URL: https://issues.apache.org/jira/browse/MYFACES-3376
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Fix For: 2.0.10, 2.1.4
>
>
> There are some complex cases we need to test inside myfaces core and other
> projects. But create those test becomes a difficult task, mostly because with
> in-container testing you have a lot of unnecessary problems setting up
> dependencies, war files, classloaders, etc. And each time they are executed
> requires time setting up/shutting down the container. In other hand, doing
> testing with mock objects like the ones in myfaces test does not work very
> well, because sometimes we need to test the "interaction" between multiple
> parts of myfaces core (viewhandler, statemanager, lifecycle ...).
> Things like org.apache.myfaces.view.facelets.FaceletTestCase are very
> productive to test such scenarios. You just provide an xhtml file, write a
> test method that take the vdl and build the view and then you add some
> asserts and that's it. These tests are very fast and very compact.
> Additionally it is very easy to debug, because you can put a break point
> directly on myfaces code and then on the test case and since it is the same
> thread running the code it becomes very easy and straightforward to follow
> the code.
> In-container testing like the alternatives already proposed in myfaces using
> Arquillian are good but for integration tests, where you need to test
> complete use cases. Here we need to test only some parts of server-side code.
> But this strategy could be useful too in such scenarios, specially because
> you can "simulate" an user input and check navigation, if pages compiles
> against facelets engine, check if the EL expressions has all managed beans,
> take statistics about the code, and much more that you just can't do it with
> the other strategy.
> The proposal I'm working on is create these classes:
> org.apache.myfaces.mc.test.core.AbstractMyFacesTestCase
> org.apache.myfaces.mc.test.core.AbstractMyFacesRequestTestCase
> org.apache.myfaces.mc.test.core.AbstractMyFacesFaceletsTestCase
> as base classes to create unit tests. The trick here is initialize/shutdown
> myfaces and provide the same variables as in MyFaces Test. So if you already
> written a junit test using myfaces test, this is not really different.
> for the client provide a class like this:
> org.apache.myfaces.mc.test.core.MockMyFacesClient
> that "hides" the client language. By default, it just takes the data directly
> from the component and fill the request parameters, header and cookies. In
> that way the client is decoupled from the test environment.
> Finally provide a MockMyFacesFaceletViewDeclarationLanguage class that
> extends from the default FaceletViewDeclarationLanguage but that add this
> method:
> public void buildView(FacesContext context, UIViewRoot view, String xmlFile)
> throws IOException
> To call it from AbstractMyFacesFaceletsTestCase, just like FaceletTestCase.
> For now my intention is add these classes to myfaces-impl test package and
> use it to see how it works and if it is worth to create a custom module for
> this one in myfaces test.
> Suggestions are welcome.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
