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. > 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. > > 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 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 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? - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
