Arnaud,
1) I have several test, 100+, and the number grows, so from a management perspective extending each abstract test in each implementation is not practical.

2) I believe a testing project can be created the will use profiles to test each implementation individually. This is a manageable workaround, although it requires an additional step to prevent a failing implementation from being deployed to the repository.

3) Ideally a "mvn deploy" would:
     o Build the implementation
     o Test the implementation, including implementation specific unit
       tests and the attached test.
     o Only deploy an artifact into the repository that has passed
       the testing.

#3 can be done by Continuum. To prevent #1 and #2 from deploying an artifact that as not passed the attached test, require 3 passes through Maven:
    o "install" the implementation.
    o Run the implementation through the attached test.
    o Only "deploy" implementation artifacts that pass all testing.

I do not believe this easily can be done in Continuum.

I suspect the result of this thread will be:
 o Corrections to the attached test documentation then include
   the requirement of creating an class in the project's testing source
   directory that extends a test located in the attached test jar.

 o A better understanding on how attached test can be used.

 o A better understanding on how attached test would like to be
   used.  Thus prompting enhancements in Maven.

Paul Spencer

Arnaud Bailly wrote:
Paul Spencer <[EMAIL PROTECTED]> writes:


Arnaud,
In my case, I have an interface with several implementations.  The
intent is it to have an attached test which verifies that the
implementation conforms to the interface.  So each implementation will
include the interface's attached test in addition to it's own unit
test. By including the attached test in each implementation, then
anytime an implementation is successfully built, by Continuum for
example, you can me assured it also confirms to the interface.

Paul Spencer


Paul,
That's nice and I think I would do the same. But then, why don't you
make four interfaces tests abstract and extends them in each module
for concrete implementations ?

abstract class ITest extends TestCase {

   abstract void setImplem(I i0);

  ITest(STring n) { super(n); }

  public void testXXX() ...

}

class ImplemTest extends ITest {

  ImplemTest(String n) {
   super(n);
   setImplem(this);
  }

  ...
}

Your attached tests will not be considered for execution, which is ok.

Regards,


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to