Typically Composition and Aggregation are treated the same? But they are different and the choice which one to use changes a lot? For e.g:
I believe aggregation would be ideal for testing. But composition is not.
Maintenance of dependencies is a pain while using aggregation but less using Composition.
So are there any similar views about the same? which one to choose, should it be only based on "part-of" and "has-a".
Aggregation, i.e. points-to, has-a-handle, has more degrees of freedom than composition, i.e. contains.
Things that can go wrong with aggregation: The subobject is destroyed too soon, it leaks, the link was never established, another object thinks it has exclusive ownership and modifies it.
Typically composition is easier for the compiler to check (such as in C++) and easier for you to check as well, as there are fewer possible uninitialized states and fewer possible means of corruption.
In general, prefer composition.
Edit: The ease of writing tests is less important than the number of tests necessary for good coverage. If your testing strategy causes you to make design decisions that increase failure modes, then it's working in reverse.
Unit testing notably doesn't expose flaws in integration. You're better off testing the subobject by a subsuite of tests on the client object. Document how each test delegates particular behavior to the subobject and how it is therefore tested, effectively and accurately, in its natural environment.
Of course, I know there are a lot of managers out there who will have nothing less than 1000 lines of thumb-twiddling code that does nothing but bind up and corrupt the overall design.
The definition followed for my post is as per here, as there are multiple definitions of association, aggregation and composition.
I feel each has it's own use:
Aggregation: Used by Object Adapter Design Pattern
Composition: Used by Composite Design Pattern
Association: Used by Many Design Patterns e.g. Observer
It is really context dependent.
Coming to testing, I think it is easier to test components which are more loosely coupled. Aggregation promotes design which are comparatively more losely coupled than those which are based on aggregation. Since testing requires configuring code components with experimental/test supplied objects. I would say that aggregation is better. You have the flexibility of configuring objects with different test objects.
If you unit test the elements forming the composition to demonstrate stand-alone correctness, then when testing the composed unit, you only need test the composed unit functionality and need not worry about the test coverage that applies to the composed elements.
That is to say, if you test bottom-up there may be no problem regarding testability. When testing the composition elements, you stub the composed unit (with a test harness), not the other way around. Test of the composed units then uses the concrete units rather than stubs.