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. 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'.
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.
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
Post by Werner GuttmannHi 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
Post by Werner GuttmannHi 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
Post by Werner GuttmannHi Andras,
Post by Andras HatvaniHello,
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
- 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, ...).
Post by Andras Hatvani- 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.
Post by Andras HatvaniAndras
Post by Werner GuttmannHi 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
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
Have a look at the project's POM as well, and I'd appreciate any
feedback or questions.
Regards Werner
http://maven.apache.org/plugins/maven-failsafe-plugin/index.html
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
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
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
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: ***@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