Re: [castor-dev] Maven and integration tests

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,
>=20
> wouldn't it be convenient to define characteristics of junit and
> integration tests before discussing about naming conventions. =46rom =
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.
>=20
> Regards
> Ralf
>=20
>=20
> Werner Guttmann schrieb:
>> Hi Andras,
>>=20
>> On 03.05.2010 21:14, Andras Hatvani wrote:
>>> Hello,
>>>=20
>>> 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=E9j=E0 vu? No, I really =
re-used
>>> this sentence ;)
>>>=20
>>> 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:
>>>=20
>>> - 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, ...).
>>=20
>>> - 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.
>>>=20
>>> Andras
>>>=20
>>>=20
>>> On 2010 May 1, at 19:32, Werner Guttmann wrote:
>>>=20
>>>> Hi all,
>>>>=20
>>>> 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.
>>>>=20
>>>> The main idea is to have a better and cleaner separation between
>>>>=20
>>>> a) unit test b) functional (integration) tests.
>>>>=20
>>>> Right now, most of the modules don't have such a clean separation,
>>>> and as such, as part of executing
>>>>=20
>>>>> mvn test
>>>>=20
>>>> both *unit* and *integration* tests will be executed, increasing
>>>> the time of the built during development.
>>>>=20
>>>> 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:
>>>>=20
>>>>> mvn clean test
>>>> ... will execute the unit tests only.
>>>>=20
>>>>> mvn clean verify
>>>> .. will execute unit and integration tests.
>>>>=20
>>>> 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.
>>>>=20
>>>> Have a look at the project's POM as well, and I'd appreciate any
>>>> feedback or questions.
>>>>=20
>>>> Regards Werner
>>>>=20
>>>> [1]:
>>>> http://maven.apache.org/plugins/maven-failsafe-plugin/index.html
>>>>=20
>>>> =
---------------------------------------------------------------------
>>>>=20
>>>>=20
>> To unsubscribe from this list, please visit:
>>>>=20
>>>> http://xircles.codehaus.org/manage_email
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> =
---------------------------------------------------------------------
>>>=20
>>>=20
>> To unsubscribe from this list, please visit:
>>>=20
>>> http://xircles.codehaus.org/manage_email
>>>=20
>>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>=20
>>   http://xircles.codehaus.org/manage_email
> --=20
>=20
> Syscon Ingenieurb=FCro f=FCr Me=DF- und Datentechnik GmbH
> Ralf Joachim
> Raiffeisenstra=DFe 11
> 72127 Kusterdingen
> Germany
>=20
> Tel.   +49 7071 3690 52
> Mobil: +49 173 9630135
> Fax    +49 7071 3690 98
>=20
> Internet: www.syscon.eu
> E-Mail: [email protected]
>=20
> Sitz der Gesellschaft: D-72127 Kusterdingen
> Registereintrag: Amtsgericht Stuttgart, HRB 382295
> Gesch=E4ftsleitung: Jens Joachim, Ralf Joachim
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>=20
>    http://xircles.codehaus.org/manage_email
>=20
>=20


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email