Hi Ralf,
On 07.05.2010 21:24, Ralf Joachim wrote:
Hi Andras, Hi Werner,
that's exactly the definition I expected.
In the past unit tests according to this definition had been put in the
test directory of the module they belong to. E.g. The unit test for a
class under 'cpa/src/main' went into 'cpa/src/test'. On the other side
integration tests had been put in separate modules.
This is true where Castor historically had already integration test
suits, mainly JDO and XML.
E.g. The integration
test for a feature of 'cpa' module got put into one of the modules
'cpactf', 'cpaptf', 'jdo-extension-it' or 'jpa-extension-it'.
True for the first two ones, but the motivation of the other ones was
slightly different. Basically, support for e.g. JPA annotations is an
enrichment of Castor JDO, but has it's roots in the JPA project. So
everything is a bit more fuzzy here .. ;-).
Werner mentioned that there may be a mix of unit and integration test in
'jpa-extension-it' module. If that's the case the unit test of this
module should be moved to 'cpa/src/test' or wherever they belong to and
the whole tests in 'jpa-extension-it' module should be treated as
integration tests according to their intensive use of external
dependencies. Doing so makes those ugly naming conventions obsolete and
should also not require yet another test module. If this solution isn't
possible or has drawbacks I'm not aware of I rely like to understand them.
Actually, we have not made any decisions here of whether we are going to
eliminate those modules completely or not. You are right that we could
move unit tests to the respective modules (core, cpa), and you
definitely got a point there. Same for the integration tests. But let's
defer this decision a but and have a look at the result, i.e. the
introduction of the failsafe-plugin on a more global level, and the
consequences to the build lifecycle (which are not unimportant). So
please bear with us as we continue work on the JPA annotations and
restructure things according to our progress.
I hope this is fine with you.
Cheers
Werner
Using the failsafe-plugin instead of the surefire-plugin for integration
test suites sounds like a great improvement according to your
description of its features.
Regards
Ralf
Andras Hatvani schrieb:
Hi Ralf,
My definition of the two test types are the following
- Integration tests are focused on components formed by more than one classes
and they use the concrete implementation of their dependencies. Such
dependencies can be: file system, network, database, 3rd party library,
components of the same project, etc.
- Unit tests are focused on single classes and they're not allowed to use
concrete implementations of their dependencies, but only test doubles (stubs,
mocks, fakes, spies, dummies) mimicking behavior desired for the test in
question.
Andras
On 2010 May 4, at 09:55, Ralf Joachim wrote:
Hi all,
wouldn't it be convenient to define characteristics of junit and
integration tests before discussing about naming conventions. From my
current point of view naming conventions based on class names are not
necessary at all as junit and integration tests already reside in
different modules.
Regards
Ralf
Werner Guttmann schrieb:
Hi Andras,
On 03.05.2010 21:14, Andras Hatvani wrote:
Hello,
Although I'm not an official committer, but within the scope of a
university course I'm involved in the development and am affected,
too, so I'd like to share my thoughts. (Déjà vu? No, I really re-used
this sentence ;)
As I'm always concerned of performance I can only
welcome the separation of unit and integration tests. Since I also
already introduced both plugins and test methods into a large code
base (Simulation of Assembly Workshops @ TU) I have a little
experience and two comments on the current implementation plan:
- I think integration-test would be the matching build phase not only
because of its name, but also due to its pre- and post-phases which
can ease the setup and teardown of the integration tests.
Yes, that's one of the major advantages when starting to use the
maven-failsafe-plugin, in that it guarantees that even when tests
fail, the post-integration phase will be executed and resources can be
torn down (e.g. DB, Jetty, ...).
- Naming conventions are usually highly subjective, so is this with the
suffix, too. However, I think that 'Case' is superfluous and if there
would be a voting I'd vote for *IntegrationTest. I know the class
names would be long, but then they would be consistent with *Test.
*IT would disturb my eyes as I don't like capitals in class names
next to each other. Again, this is highly subjective.
I know. And I am perfectly fine with *IntegrationTest.
Andras
On 2010 May 1, at 19:32, Werner Guttmann wrote:
Hi all,
I have started to introduce the maven-failsafe-plugin to our build.
Please see [1] for a very good and detailed explanation about the
working(s) of this plugin.
The main idea is to have a better and cleaner separation between
a) unit test b) functional (integration) tests.
Right now, most of the modules don't have such a clean separation,
and as such, as part of executing
mvn test
both *unit* and *integration* tests will be executed, increasing
the time of the built during development.
Once this new plugin has been introduced project-wide, and all the
integration tests have been 'marked' as such, the will be a clean
separation at the Maven level:
mvn clean test
... will execute the unit tests only.
mvn clean verify
.. will execute unit and integration tests.
So far, I have introduced the usage of the maven-failsafe-plugin to
the jpa-extensions-it module only, and configured it to use the
*ITCase suffix to establish integration tests. To showcase things,
I have renamed one of the existing functional tests (testing the
support of the JPA @NamedQuery annotation) so far.
Have a look at the project's POM as well, and I'd appreciate any
feedback or questions.
Regards Werner
[1]:
http://maven.apache.org/plugins/maven-failsafe-plugin/index.html
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany
Tel. +49 7071 3690 52
Mobil: +49 173 9630135
Fax +49 7071 3690 98
Internet: www.syscon.eu
E-Mail: ralf.joac...@syscon.eu
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
