Xml Functional Tests - Where Should They Live?

[andrew cooke-2]

Almost all the tests for the XML module are in the VM package to avoid
dependency loops in Maven (VM is used as the transport to test filters
that operate on XML payloads, etc; the VM tests depend on
mule-tests-functional which depends on mule-module-xml, so making XML
tests depend on VM would add a loop).

One way to avoid this is to put the tests in mule-tests-integration, but I
am reluctant to do that given that those do not run in CI.

Any other suggestions/ideas on how better to arrange this?

Thanks,
Andrew



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

    http://xircles.codehaus.org/manage_email

[Andrew Perepelytsya]

Put them in a more specific integration tests module once there is one (later).

Andrew

On 10/2/07, andrew cooke <acooke@...> wrote:

Almost all the tests for the XML module are in the VM package to avoid
dependency loops in Maven (VM is used as the transport to test filters
that operate on XML payloads, etc; the VM tests depend on
mule-tests-functional which depends on mule-module-xml, so making XML
tests depend on VM would add a loop).

One way to avoid this is to put the tests in mule-tests-integration, but I
am reluctant to do that given that those do not run in CI.

Any other suggestions/ideas on how better to arrange this?

Thanks,
Andrew



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

    http://xircles.codehaus.org/manage_email

[Ross Mason-3]

They could go into the functional-tests module

Cheers,

Ross Mason
MuleSource

Malta Tel: [phone]
UK Tel: [phone]
US Tel: [phone]





On 2 Oct 2007, at 19:40, andrew cooke wrote:

>
> Almost all the tests for the XML module are in the VM package to avoid
> dependency loops in Maven (VM is used as the transport to test filters
> that operate on XML payloads, etc; the VM tests depend on
> mule-tests-functional which depends on mule-module-xml, so making XML
> tests depend on VM would add a loop).
>
> One way to avoid this is to put the tests in mule-tests-
> integration, but I
> am reluctant to do that given that those do not run in CI.
>
> Any other suggestions/ideas on how better to arrange this?
>
> Thanks,
> Andrew
>
>
>
> ---------------------------------------------------------------------
> 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

[andrew cooke-2]

I wondered about that, but the functional tests module seems to be more
"support for functional tests" than functional tests itself.  That means
that almost every test depends on mule-tests-functional and again I think
we get a loop (VM tests depend on mule-tests-functional which would depend
on VM).

I think they should go in something like a "functional tests" module
(which is what Andrew suggested too, I think), but the current
mule-tests-functional doesn't seem to be it (and should perhaps be renamed
to mule-module-functional-tests or similar?)

Does that make sense?

Andrew

> They could go into the functional-tests module
>
> Cheers,
>
> Ross Mason
>
> On 2 Oct 2007, at 19:40, andrew cooke wrote:
>
>>
>> Almost all the tests for the XML module are in the VM package to avoid
>> dependency loops in Maven (VM is used as the transport to test filters
>> that operate on XML payloads, etc; the VM tests depend on
>> mule-tests-functional which depends on mule-module-xml, so making XML
>> tests depend on VM would add a loop).
>>
>> One way to avoid this is to put the tests in mule-tests-
>> integration, but I
>> am reluctant to do that given that those do not run in CI.
>>
>> Any other suggestions/ideas on how better to arrange this?
>>
>> Thanks,
>> Andrew
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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

[Holger Hoffstätte-2]

andrew cooke wrote:
> I wondered about that, but the functional tests module seems to be more
> "support for functional tests" than functional tests itself.  That means
> that almost every test depends on mule-tests-functional and again I think
> we get a loop (VM tests depend on mule-tests-functional which would depend
> on VM).

Yup, right about the loop.

> I think they should go in something like a "functional tests" module
> (which is what Andrew suggested too, I think), but the current

What AP suggested is that pretty much exactly what I tried to point out
several times now too, namely that tests that cross compilation units
(artifacts in maven-speak) are actually integration tests which need to go
into their own separate artifacts as well, simply because there is no
other way to avoid the cycles. Each of these integration-test projects
should probably be named after the "tested" dependency, pulling the others
in as needed. So your XML "functional-but-really-integration" test project
could be called e.g. tests/integration-module-xml.

> mule-tests-functional doesn't seem to be it (and should perhaps be renamed
> to mule-module-functional-tests or similar?)

Sounds OK to me since it is essentially the "functional" brother of the TCK

-h

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

    http://xircles.codehaus.org/manage_email

[Holger Hoffstätte-2]

Holger Hoffstätte wrote:
[..]
> other way to avoid the cycles. Each of these integration-test projects
> should probably be named after the "tested" dependency, pulling the others
> in as needed. So your XML "functional-but-really-integration" test project
> could be called e.g. tests/integration-module-xml.

..or maybe "xml-integration" in the "modules" branch, just to be
consistent. That way things don't diverge so easily, and integration tests
for both modules and transports can be created incrementally from the
existing suite.

-h


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

    http://xircles.codehaus.org/manage_email