...
Read this jira issue for some details.
http://jira.codehaus.org/browse/MNG-32
current location of harness
...
above are taken care of. Notice the projectArtifact element above with the implementation="" attribute. This is how you will inject the StubArtifact implementation into that projectArtifact private variable on the mojo. Additional elements can be inserted as child elements and they will in turn be assigned to the variables inside that object. An example would be setting the groupId variable on the StubMavenProject. Note: these internal variable might also need implementation="" attributes.
another way to use the harness
There is another way to use the harness if the above solution isn't desired, but it is a bit more dangerous perhaps and requires pretty good legwork to make sure it doesn't blow up, but in some circumstances it might just make life easier.
The AsbtractMojoTestCase has another utility method on it for setting a value of variables in an object that might not have a setter.
Code Block |
---|
protected setVariableValueInObject( Object object, String variable, Object value) throws IllegalAccessException
|
This should allow you to populate most, if not all of the mojo as you need, depending on the depth to which it needs to be configured. Here is an example on how it could be used.
Code Block |
---|
public void testSettingMojoVariables()
throws Exception
{
SimpleMojo mojo = new SimpleMojo();
setVariableValueToObject( mojo, "keyOne", "myValueOne" );
assertEquals( "myValueOne", (String)getVariableValueFromObject( mojo, "keyOne" ) );
}
|
Or I would even be used in conjuction with the above mechanism to tweak a value.
Code Block |
---|
public void testSettingMojoVariables()
throws Exception
{
SimpleMojo mojo = lookupMojo( "simple", "path-to-test-pom" );
setVariableValueToObject( mojo, "keyOne", "myValueOne" );
assertEquals( "myValueOne", (String)getVariableValueFromObject( mojo, "keyOne" ) );
}
|
Great care should be taken in the writing of tests using the approach since there are none of the safeguards in place that plexus provides for this sort of variable injection. However, this should help us in sticky situations were we need to change/set the value of a variable in an object that might not have a setter. Note: this setVariableValueToObject is generic and can work in all sort of objects that you might need. Also, whereas plexus will use the objects setter for the variable if it exists, this will not.
useful things to know
There are a couple of utility methods on the AbstractMojoTestCase that should make the asserts easier to work with.
...
I have noticed that since the declaration of the patchs are not directly in the same location as the verification (one being with the plugin configuration and the other in the assert clauses) that it is very easy to get them mixed up. And if you are validating that the file doesn't exist at the end of the operation as with the clean plugin, if you are not testing the absolute right thing then your assert will be working when the test itself might have failed. So make sure you check these conditions, perhaps even asserting something is there before the mojo execution and then asserting it isn't there at the end.
this might actually be made easier with the addition of the ability to set and get variables in the instantiated mojo from the java side of the fence