Brett Porter wrote:
Jason van Zyl wrote:
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.
A stub of the maven project builder, or the real one? The real one uses
the repo, and that's not really conducive to unit testing.
The harness somewhat blurs the lines but once you execute the Mojo I
don't really consider it a unit test anymore. Even with the simple clean
plugin example that you started with executed the Mojo. I think that's
what's useful for testing and many Mojos need a local repository so I
was suggesting using the real project builder passing in a local
repository created for testing purposes.
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.
At one point, we were doing away with private field injection and
recommending setters, so it is how they'd be used.
Hasn't happened yet. Not sure if that will happen as I'm not sure how
many Ant tasks are actually used outside of Ant. Given what we do in
promoting the creation of components that get wrapped by a Mojo to
expose them in Maven I'm not sure if there's much point to properties.
If that's what we decide then we can do that. I'm not fussed one way or
the other.
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.
No, neither do I. I said having both is a good idea, but that calling it
a POM is misleading, and to cut it back to just a configuration.
But there are plugins that require a MavenProject and other parts of the
POM not in the configuration for the plugin.
The IDEA plugin is one example that needs a POM so having the pom.xml
file actually be the source of a MavenProject I think would work. There
is also the resources plugin which requires elements in the <build/>
element. I don't think we'll get away with just the <configuration/>
element for the plugin.
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.
But they *are* properties, it's just a matter of whether it is injected
using private fields, setters or constructors. Adding getters is
probably a bit more lame, but I think that's unavoidable in either case.
We've had this discussion before :-) They are not properties. We happen
to abuse the field name being the same as the configuration element. But
with a property the configuration element can be different then the
field name as the setter would intervene.
I think the Artifact/MavenProject population could use a little tweaking
but we could probably do that with a special expression evaluator.
Cool. I have to look at the actual code yet...
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.
In some cases, but when you are only setting one field, its a pain, and
when you are doing the same thing over and over and changing one field,
it's a pain (though you could combine the two techniques for that).
In how many cases in a Mojo can you only set one field and actually make
it do anything? I'm all for a Java way, but I think the pom.xml will be
the most thorough and actually correspond most accurately to real use.
Whatever kind of testing that actually is.
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.
As long as the assertions are still in Java, I don't think its a
declarative option, and I'd prefer to have my pre-conditions next to the
post-conditions to make the tests more readable, myself.
But, we can do both, and learn from experience which works, right?
In SuiteRunner the input and assertions were in the same file. Sure, it
can't hurt to have both methods and I think we need a method in Java
simply because we will probably find holes in the declarative structure
and that shouldn't stop you from testing.
- Brett
---------------------------------------------------------------------
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]
