Brett Porter wrote:
Just some things for the record:
- I don't really like the <artifact>...</artifact> element here as it
isn't normal to a POM.
- The POM doesn't do the full inheritence thing, so it might not behave
as expected. This could be confusing
I think if the file is not really a POM, it shouldn't be construed as
one for the sake of clarity. Maybe we can just use the normal Xpp3Dom
configuration lookup, and that can be created from xpp3 dom builder from
a file with just the config element.
This was just the first stage. I just whacked in the DOM reader because
we need some more testing code to create a local repository for the
MavenProjectBuilder. The MavenProjectBuilder should be used.
I assume if there are project elements to be populated that are not part
of a plugin, they would be set on the stub project housed in the stub
expression evaluator, which could be done in java code?
Also:
- I think we should be adding getters/setters and being able to
construct a normal mojo and set fields by hand (components and
expressions should still be prepopulated in the lookup).
Why? I don't think you should have to add methods in order to be able to
test the mojos. It's not how they would ever be used, so you're not
really testing how they would be used in the field by adding properties.
I think the POM style testing will be most familiar to people writing
plugins and ultimately allows for completely declarative testing of
Mojos which I think would be excellent. In almost all cases you have to
execute the mojo in order to test it and in order to execute it you need
to populate the configuration elements. You could very clearly outline
different test scenerios using different POMs. You could do this in Java
but does it really matter if the inputs come via Java or another
mechanism? I honestly don't think so.
At any rate I don't think you should alter classes for testing.
Especially in this case as we know Mojos work just fine without properties.
I think the Artifact/MavenProject population could use a little tweaking
but we could probably do that with a special expression evaluator.
I think people writing tests will like this declarative method of
writing tests. It will be less error prone and take less effort and
provide a standard way for writing Mojo tests.
That was what I thought was beautiful about SuiteRunner, the same
notions I pushed into Surefire, where test invocation can come from
anywhere: Java, XML, text files. The same idea used in Fitnesse where
users can write tests for webapps using simple markup.
I think we can easily provide some Java code for those that want to do
the Java thing but I imagine the desire to do that would fade given the
declarative option. But you still shouldn't have to add properties to a
mojo to make that work unless that's what you wanted to do to make it
reusable.
It seems like most of this is in place, just issues of clarity and
perhaps preference.
Thanks again!
- Brett
Jesse McConnell wrote:
we can now inject StubArtifacts into the mojo's :)
<project>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compileSourceRoots>
<compileSourceRoot>src/main/java</compileSourceRoot>
</compileSourceRoots>
<compilerId>javac</compilerId>
<outputDirectory>target/classes</outputDirectory>
<artifact>org.apache.maven.artifact.Artifact</artifact>
</configuration>
</plugin>
</plugins>
</build>
</project>
for the time being I am sticking all of the Stub* maven artifacts in the
maven-plugin-testing-harness and they are all referenced in the
components.xml file in the same project. I am not sure if we want them to
ultimately reside next to the Default* implementations or not...anyone have
thoughts on that? I could go either way on that.
I am pretty however pretty happy with the way this is fleshing out :)
very useful and by the time more unit tests are written we should have a
pretty decent set of stub's for mojo's to work with.
Not everything will have to be a stub either here, jason is working on the
ArtifactRepository and aggregating some things together but I can see the
need where we are going to need a real one or more of those since some
plugins make use of it...the axistools plugin for one :)
cheers,
jesse
On 2/23/06, Jesse McConnell <[EMAIL PROTECTED]> wrote:
updating this thread again
Jason and I talked over the above idea and he took a few minutes and put
together the basic jist of the concept and shoved it into the mojo-sandbox
so I could work with it.
mojo-sandbox/maven-plugin-testing/maven-plugin-testing-harness
that has version 1.0-SNAPSHOT of the AbstractMojoTestCase which is what
the test cases can subclass from to get the ability to dynamically load the
mojo based on an arbitary pom.
I modified the maven-clean-plugin again to make use of this and it turned
out quite well I'd say.
/**
* tests the ability of the plugin to clean out a set of directories
*
* @throws Exception
*/
public void testClean() throws Exception {
CleanMojo mojo = (CleanMojo) lookupMojo ("clean", testPom );
assertNotNull( mojo );
mojo.execute();
assertFalse ( FileUtils.fileExists(
"target/test/testDirectoryStructure/buildDirectory" ) );
assertFalse ( FileUtils.fileExists(
"target/test/testDirectoryStructure/buildOutputDirectory" ) );
assertFalse ( FileUtils.fileExists(
"target/test/testDirectoryStructure/buildTestDirectory" ) );
}
This method in the CleanMojoTest class coupled with this pom.xml @
src/test/resources/unit/clean/pom.xml execute the unit test very easily.
<project>
<build>
<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<configuration>
<directory>target/test/testDirectoryStructure/buildDirectory</directory>
<outputDirectory>target/test/testDirectoryStructure/buildOutputDirectory</outputDirectory>
<testOutputDirectory>target/test/testDirectoryStructure/buildTestDirectory</testOutputDirectory>
</configuration>
</plugin>
</plugins>
</build>
</project>
I am going to take this approach and work on testing another plugin in
maven now, get a couple of plugins under my belt with this and the abstract
base class ought to be pretty tight.
jesse
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
