[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ormf-dev] Guide to ORMF repository structure
|
On 7 Oct 2008, at 07:47, Achim Loerke wrote:
See below...
Joel Rosi-Schwartz wrote:
Thanks for the suggestions...
On 6 Oct 2008, at 18:15, Achim Loerke wrote:
Comments on the document:
The overall structure looks good to me.
The current SVN repository contains a few projects which do not
use the naming convention "org.eclipse.ormf...", namely plugins/
{ormf,useme}/test. Is this the intended form or a leftover from
the initial commit? At least it's not a good idea to have more
than one Eclipse projects with the same SVN name.
The "test" folders are containers (not projects) in which all of
the test plug-in fragments will live. We kept these isolated to
reduce the clutter in the parent folder. The rationale was that
most adopters would be primarily (at least in the first instance)
interested in the real source and not the junit tests. I agree with
you absolutely that all projects should have very clear,
unambiguous and unique names.
I was about to discuss a different approach for the "Guide to test
artifacts and procedures": put the junit tests in the same plug-in
project, but in a different source folder. Typically you have one
source folder called 'src' in a plug-in project. By adding a second
source folder called 'tests' you can use the same package structure
for the junit test cases and have them neatly separated from your
source code.
The pro's:
* Access to package visible class members. This is an often used
approach to do some white box testing.
* No problems with inter plug-in dependencies.
* Code and tests are organized in the same project.
* Works well with the "Create unit test" wizard in Eclipse IDE.
The con's:
* The junit tests have access to API, classes, members which are not
part of the public interface. This can be a good thing (see above)
but also lets you write tests which work different from the real
world use of the tested classes.
* ... You tell me :-)
B. should really reply to this one, but I have one question that is
nagging at me. If the junit src is in the same plug-in, then do we not
have a dependency on junit that has to be satisfied during deployment?