ICEfaces
  1. ICEfaces
  2. ICE-3262

Investigate use of JSFUnit for testing purposes

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.7.1
    • Fix Version/s: 1.8.1
    • Labels:
      None
    • Environment:
      Test

      Description

      Take a look at the feasibility of using JSFUnit for developer oriented testing of our modules, classes, apps, etc.

        Activity

        Hide
        Greg Dick added a comment -

        I have created a JSFUnit test for an existing ICEfaces application., I declared the existing application as a dependency in my test application which is all good and I can write code to verify various items in the output of the page. According to this page, however, I see I need to copy the web.xml file from my existing application and modify it to contain servlet settings for JSFUnit and to create a 'stub' web application for JSFUnit. JSFUnit then merges the two web applications

        It seems like I should be able to obtain a reference to the FacesContext available to application on the server. According to the following link, there is some ThreadLocal manipulation required to make this possible and the API seems to support this. However, at any point in the JSFUnit test code when I try to retrieve the instance (essentially from the JSFUnit thread, not the cactus application calling thread as I understand it) its value is null.
        http://www.jboss.org/community/docs/DOC-10963

        The ICEfaces blocking request strategy and server push. While JSFUnit supports Ajax requests by allowing the components to fire their native javascript, support for ICEfaces blocking receive-updated-views and receive-updates + merging of the updates into the JSFUnit DOM is an unsupported operation.
        http://www.jboss.org/community/docs/DOC-10971

        Show
        Greg Dick added a comment - I have created a JSFUnit test for an existing ICEfaces application., I declared the existing application as a dependency in my test application which is all good and I can write code to verify various items in the output of the page. According to this page, however, I see I need to copy the web.xml file from my existing application and modify it to contain servlet settings for JSFUnit and to create a 'stub' web application for JSFUnit. JSFUnit then merges the two web applications It seems like I should be able to obtain a reference to the FacesContext available to application on the server. According to the following link, there is some ThreadLocal manipulation required to make this possible and the API seems to support this. However, at any point in the JSFUnit test code when I try to retrieve the instance (essentially from the JSFUnit thread, not the cactus application calling thread as I understand it) its value is null. http://www.jboss.org/community/docs/DOC-10963 The ICEfaces blocking request strategy and server push. While JSFUnit supports Ajax requests by allowing the components to fire their native javascript, support for ICEfaces blocking receive-updated-views and receive-updates + merging of the updates into the JSFUnit DOM is an unsupported operation. http://www.jboss.org/community/docs/DOC-10971
        Hide
        Greg Dick added a comment -

        The FacesContext instance available to JSFUnit when testing ICEfaces applications is null because ICEFaces does not take part in the FacesContextFactory and FacesContext delegation properly. The reason for this turns out to be the information required by the BridgeFacesContext is not available through the factory API.

        This is the API offered by the FacesContextFactory:

        public abstract FacesContext getFacesContext (Object context, Object request, Object response, Lifecycle lifecycle)

        This is currently the constructor of the BridgeFacesContext:

        (Request request, final String viewIdentifier, final String sessionID, final View view, final Configuration configuration, ResourceDispatcher resourceDispatcher, final SessionDispatcher.Monitor sessionMonitor, final Authorization authorization)

        A lot of these arguments are simply passed on to the constructor of the ExternalContext in either Servlet or Portlet flavours, whereas the JSF Factory method passes in the external context.

        Perhaps this can be refactored to use the Factory method.

        Show
        Greg Dick added a comment - The FacesContext instance available to JSFUnit when testing ICEfaces applications is null because ICEFaces does not take part in the FacesContextFactory and FacesContext delegation properly. The reason for this turns out to be the information required by the BridgeFacesContext is not available through the factory API. This is the API offered by the FacesContextFactory: public abstract FacesContext getFacesContext (Object context, Object request, Object response, Lifecycle lifecycle) This is currently the constructor of the BridgeFacesContext: (Request request, final String viewIdentifier, final String sessionID, final View view, final Configuration configuration, ResourceDispatcher resourceDispatcher, final SessionDispatcher.Monitor sessionMonitor, final Authorization authorization) A lot of these arguments are simply passed on to the constructor of the ExternalContext in either Servlet or Portlet flavours, whereas the JSF Factory method passes in the external context. Perhaps this can be refactored to use the Factory method.
        Hide
        Greg Dick added a comment -

        We check to see if JSFUnit classes are present on the classpath, and if so, put the BridgeFacesContext into the Map just as the JSFUnit code did, still however without using proper delegation.

        Show
        Greg Dick added a comment - We check to see if JSFUnit classes are present on the classpath, and if so, put the BridgeFacesContext into the Map just as the JSFUnit code did, still however without using proper delegation.

          People

          • Assignee:
            Unassigned
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: