Our feature projects (for the products we build) do NOT include the test fragments, which means test code does not get included in the built product. However, each host plugin has a buckminster.cspex which lists the test fragment as a dependency - note however that it's NOT listed in the manifest as a plugin dependency. This ensures that that when a developer checks out (materializes) a plugin, they also get the associated test fragment.
Another thought on test plug-in organization. We have test plug-ins also as fragments but we have a test feature that complements each non-test feature, and the test feature provides the test plug-in fragments. Our 'site' feature which contains the cquery and rmap includes the top level application feature and the top level test feature. Thus, when you materialize with the cquery, you get the plug-ins and the test fragments.
Also you can set the eclipse preferences to display missing plug-ins from a feature as errors, so as a developer, you know if you are missing any test plug-ins.
On 2011-11-25 12:06, Bernhard Lutzmann wrote:
> Thanks for the responses.
> Yes, I was also thinking about using test fragments. And it seems when using Buckminster this is the proper way.
> The only side-effect that I don't like is that the number of projects grow.
I would consider that a good sign. ;-)