3 Replies Latest reply on May 14, 2008 3:21 PM by starksm64

    Scope of the Proxy Component

    alrubinger

      We've defined a test in EJB3 Proxy which goes beyond scope of the Proxy component. :)

      Because we've granted jboss-metadata the authority/responsibility to define the resolved JNDI names, Proxy's job ends so long as lookups and invocations to the JNDI name obtained from metadata succeed. We can't have tests looking for bindings in any particular form (ie. MyStatelessBean/remote).

      Because Proxy will be getting the JNDI names from metadata, just as the Client container does, it doesn't matter what the JNDI names are; they'll match.

      If we want to check that JNDI names follow the exected format, those tests belong in jboss-metadata alongside the DefaultJndiBindingPolicy implementations.

      S,
      ALR

        • 1. Re: Scope of the Proxy Component
          wolfc

          We have a requirement that states: 'Given deployment X proxies must show up in global JNDI under x/y.'

          Clearly it is the responsibility of the proxy component to satisfy this requirement, so the test is a post condition for the component.

          The fact that proxy has delegated the JNDI naming function to jboss-metadata for integration with client is a low level detail. It does not absolve proxy of its responsibility.

          As long as the above requirement is not met (/ test fails) proxy is at fault and because of the delegation jboss-metadata might be at fault as well. So we must have tests in jboss-metadata to ascertain its correctness and the same goes for proxy.

          The only discussion point I see is that it's not an unit test. In this I say that we want to have incremental integration, so that faults are spotted earlier than the full integration test (which also takes a bit more time). Ergo proxy must pass this test.

          • 2. Re: Scope of the Proxy Component
            alrubinger

            So this debate is actually, "What *is* the scope of the Proxy Component?" :)

            I maintain that Carlo's stated requirement is a "business requirement" of EJB3, and therefore should be tested by EJB3 Integration Tests. Additionally, I believe this is achieved through two "functional requirements" of disparate components:

            * jboss-metadata must return Strings of the JNDI Names in correct form
            * EJB3 Proxy must return appropriate proxies from whatever addresses are specified by jboss-metadata.

            The fundamental difference is that I disagree with:

            "wolfc" wrote:
            Clearly it is the responsibility of the proxy component to satisfy this requirement, so the test is a post condition for the component.


            From a more generic perspective, I'm not familiar with this notion of "Component Testing":

            A is a Component
            B consumes A
            This forms another Component (A,B)
            B is responsible for testing A to certify (A,B) is OK.

            The above is from Carlo's reference http://www.faqs.org/faqs/software-eng/testing-faq/section-14.html

            By the above definition, each component we have would be responsible for running acceptance tests on the libraries it consumes (dependent upon the risk factor at stake).

            I'm more aligned with the Agile Community's stance on acceptance testing, which says that it's done at the user story (ie. final integration) level (http://en.wikipedia.org/wiki/Acceptance_testing#Acceptance_Testing_in_Extreme_Programming).

            S,
            ALR

            • 3. Re: Scope of the Proxy Component
              starksm64

              Having to configure the actual server deployers to obtain the metadata is certainly out of scope, and overkill. All we need to validate is that given a metadata instance that the proxy factory produces the expected bindings. The jndi names are already being validate in the metadata unit tests. Just create the minimal JBossMetaData/JBossEnterpriseBeanMetaData and validate it drives the expected bindings. Anything beyond that is integration testing that affects the metadata. As long as all metadata cases are covered, the proxy component is tested.