6 Replies Latest reply on Mar 5, 2008 9:56 AM by Ales Justin

    WiredMicrocontainerTest

    Adrian Brock Master

      This should not be in src/main. Either add the feature to the MicrocontainerTest class
      or move it to src/tests

        • 1. Re: WiredMicrocontainerTest
          Ales Justin Master

           

          "adrian@jboss.org" wrote:
          Either add the feature to the MicrocontainerTest class or move it to src/tests

          I don't want all the tests to be autowired.
          But on the other hand this is a generic MC test util, so imho it should be where it is.
          As a user I don't want to pull all the kernel tests just to get what the kernel module is all about, this test. :-)

          • 2. Re: WiredMicrocontainerTest
            Adrian Brock Master

             

            "alesj" wrote:
            "adrian@jboss.org" wrote:
            Either add the feature to the MicrocontainerTest class or move it to src/tests

            I don't want all the tests to be autowired.
            But on the other hand this is a generic MC test util, so imho it should be where it is.
            As a user I don't want to pull all the kernel tests just to get what the kernel module is all about, this test. :-)


            MicrocontainerTest is the exported test. I don't want lots of different test parents
            with the N<->M problem for different features.

            I already went through and fixed this once and combined three or four classes
            you'd created in the package back into the main test class. :-)
            There's a previous thread about it somewhere?

            The correct way to do this, if you want subclasses to use it is to allow it to be
            enabled with something like:

            public MyTest(String name)
            {
             super(name);
             // or whatever you want to call the property
             setRegisterTestInController(true);
            }
            


            The same goes for any other features you think are generic enough
            to be used elsewhere.


            • 3. Re: WiredMicrocontainerTest
              Ales Justin Master

               

              "adrian@jboss.org" wrote:

              I already went through and fixed this once and combined three or four classes you'd created in the package back into the main test class. :-)
              There's a previous thread about it somewhere?

              You call it 'N<->M problem', I call it OO approach. :-)

              OK, I'll fix this one into the MicrocontainerTest.
              Plus any other future crazy generic idea that I get. ;-)

              • 4. Re: WiredMicrocontainerTest
                Adrian Brock Master

                 

                "alesj" wrote:
                "adrian@jboss.org" wrote:

                I already went through and fixed this once and combined three or four classes you'd created in the package back into the main test class. :-)
                There's a previous thread about it somewhere?

                You call it 'N<->M problem', I call it OO approach. :-)


                No. If it is OO you ask the question, isA (inheritance) or hasA (encapsulation)

                In this case it isn't very clear, you can make arguments for either.

                My test isA wired test
                My test hasA wired controller registration

                In general, if it is not clear, use hasA because it avoid the N<->M problem
                (absent multiple inheritance :-) and enables greater reuse.

                NOTE: Many people would argue that setters are not a correct use of encapsulation
                (I just call it externalising the policy ;-).

                But you can just make it a protected setter if you think it really breaks encapsulation
                and you want policy controlled by subclasses (that ways its really no different from
                constructor parameters except you don't have to create 5,000 constructors
                for all the different policy parameters and their permutations. :-)

                • 5. Re: WiredMicrocontainerTest
                  Adrian Brock Master

                   

                  "adrian@jboss.org" wrote:

                  hasA (encapsulation)


                  HUMPTY DUMPTY again

                  Some people refer to this as aggregation rather than encapsulation,
                  but I prefer to restrict that word to when you are creating
                  composite objects from other objects.

                  e.g. our DeploymentContext aggregates attachments and vfs elements.


                  • 6. Re: WiredMicrocontainerTest
                    Ales Justin Master

                    WiredMicrocontainerTest has been removed.
                    It's functionality has been moved to its superclass, MicrocontainerTest.
                    Set the autowireCandidate flag to true to enable it.