| Re: [platform-ui-dev] Policy of the Platform projects with regards to tests accessing non-public members |
Yeah, I'm fine with adding a test fragment instead of modifying the current test plugin to a fragment. In my case (org.eclipse.core.filebuffers.tests) that would indeed mean a few unrelated changes that might make the review harder. There is a another test plugin that depends on the org.eclipse.core.filebuffers.tests plugin, there's helper code that uses the activator / plugin resources, etc.On 9 March 2016 at 07:52, Dirk Fauth <dirk.fauth@xxxxxxxxx> wrote:First, Require-Bundle is bad and we should always prefer Import-Package. The Require-Bundle stuff introduces more problems than it tries to solve.
I'm not sure I agree, but that would be a separate discussion. Is there some blog post on this that I can read later?Second, test fragments are fine for white box testing in an OSGi context. Test plugins are used for black box and integration testing. So IMHO it would be also ok to add a new test fragment for the white box tests you want to introduce and keep the current test plugin to keep the integration test capability.
For the sake of less code changes to existing code, I agree. Less entropy. But just to be clear, if one is starting out, I don't see a benefit in a strict rule saying one should separating white and black box tests into different bundles (one fragment, one plugin). You can still do black box testing in a fragment (and if you use something like an API Java interface, you'll be prevented from accessing white-box/internal concerns). But it's more than that, I believe it sometimes it's best to have white-box and black-box testing co-located.
IMO, *pure* black-box testing is over-rated, and also kinda utopian - it can often be impractical. For example, sometimes you might set out to write a black-box only series of tests, but then there is this one aspect you wanna check at some point in your tests, for which there should be a public API... but there isn't one. You can check it accessing some white-box internals. What do you do? Do you forego that particular check, thus making yours tests less comprehensive, just so you can say your tests remain black-box in their entirety?
Good black box tests require good, comprehensive, well designed public APIs for the code being tested, which is often not the case...
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev