This content has been marked as final.
Show 6 replies
-
1. Re: WiredMicrocontainerTest
alesj Mar 5, 2008 7:19 AM (in response to adrian.brock)"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 Mar 5, 2008 7:44 AM (in response to adrian.brock)"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
alesj Mar 5, 2008 8:00 AM (in response to adrian.brock)"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 Mar 5, 2008 8:20 AM (in response to adrian.brock)"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 Mar 5, 2008 8:28 AM (in response to adrian.brock)"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
alesj Mar 5, 2008 9:56 AM (in response to adrian.brock)WiredMicrocontainerTest has been removed.
It's functionality has been moved to its superclass, MicrocontainerTest.
Set the autowireCandidate flag to true to enable it.