Skip to main content

[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?


Back to the top