3 Replies Latest reply on Apr 24, 2008 9:28 AM by ssilvert

    Using JSFUnit for testing applications using foreign templat

    westenb

      Hello,

      I am currently evaluating the usage of JSFUnit for testing applications using a set of template libraries (facelets) by internal and external providers.

      Obviously, I am trying to avoid any depedencies to implemetation details of the corresponding templates. However, even for a basic example of a compound control consisting of a label and an input field it is not entirely clear to me how to avoid a dependency to the client ID creation algorithm of the template defintion (i.e. what is the used ID of the inputText in the HTML?).

      Does anyone have a recommendation how to solve this in a clean way (possibly with the help of the provider of the specific template lib)?
      Is there for example a way to address object via XPath?

      Best regards,
      Eric

        • 1. Re: Using JSFUnit for testing applications using foreign tem
          ssilvert

          I'm not entirely sure I understand your question, but I don't think you will have a problem unless you are using portlets. As long as these are JSF components then the client ID's will be generated in the standard JSF way, which JSFUnit understands.

          See http://wiki.jboss.org/wiki/UsingComponentIDs

          Stan

          • 2. Re: Using JSFUnit for testing applications using foreign tem
            westenb

            Thanks for the reply but I think I did not explain my scenario well enough.

            I have the following basic application development scenario in mind:

            - a control / template library is provided by some organization A
            - this library is used for application development by another organization B

            I would like to understand what is required in order for organization B to write JSFUnit tests for their applications with only minimal dependencies to the implementation details of the control library.

            Example: Assume the control library contains a facelet tag <foo:inputfield> defined as follows:
            <ui:composition>
            <h:outputLabel id="${controlId}_label" for="${controlId}_input" styleClass="label" value="${controlLabel}" />
            <h:inputText id="${controlId}_input" value="${controlValue}" />
            </ui:composition>

            So the application page could contain a tag such as
            <foo:inputfield controlId="myId" label="myLabel" />

            Now assume I would like to write a JSFUnit test for the application page and set the value of the input field. Then it seems to me that I need to use my knowledge about the ID creation used in the template defintion (i.e. that the inputText has ID "${controlId}_input").

            What would be a good way to resolve this, resp. minimize the impact?

            Eric

            • 3. Re: Using JSFUnit for testing applications using foreign tem
              ssilvert

              OK, I think I understand your question a little better now.

              You will have to know something about the implementation of the composition to set any kind of value. After all, you must know that some input field exists to know that you can set it.

              JSFUnit does a simple substring match on the end of the ID when it looks up the component. So in your example, the <h:inputText> could be found by JSFUnit like this:

              jsfClientSession.setParameter("_input", "myvalue");

              However, that doesn't help you much because you need to know about the "_input" string and you will likely get a DuplicateClientIDException because JSFUnit will probably find more than one component ID that matches.

              There is no XPath support for component ID's, but you might be able to search for the ID using JSF's UIComponent.findComponent("expression").getClientId()

              findComponent() can be pretty tough to use though. For now, I think that the best you can do is to set a standard that organization A uses when it creates components. Maybe you can at least have enough consistency in how the component ID is created that you don't have to know too much about the implementation.

              Stan