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