On 3/6/06, Brett Porter <[EMAIL PROTECTED]> 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 repo will need to be real at some point, some plugins needs to interact
with the real thing, for getting jars for packaging or for just looking into
for resources or something..so the artifact repo seems to be a required part
of actual unit tests..
> 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.
>
> >
> > 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.
simple, I'll take care of this today... <plugin>-config.xml maybe?
>
> > 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?
I think we can get away with all this without actually needing to add
getters and setters, personally I think adding setters somewhat clouds the
interaction with mojo's, have a combo of setters and private field injection
seems prone to some kind of abuse
> 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).
I was getting visions of people just making one test pom and either reusing
or copying and modifying a bit.
> 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.
I agree with you here, it is disjointed to have the configuration and the
asserts in another place...but if we are going to route of a new file for
configuring these things, how about just building out an assert setup in the
configuration xml?
<test>
<configuration>
...
</configuration>
<asserts>
<assertTrue>expression</
..
..
The expression could be fed into the test case somehow...then they are bound
together
jesse
--
jesse mcconnell
jesseDOTmcconnellATgmailDOTcom
