Message-ID: <1876969144.3546.1369385853899.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3545_401574974.1369385853899" ------=_Part_3545_401574974.1369385853899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Read this jira issue for some details.
The harness provides an abstract base class for testing plugins and an i= ncreasing collection of stub implementations of key maven classes. Many of= your plugins contain plexus components which should be populated by the co= ntainer so in your test cases you will be 'looking up' a mojo and then eith= er using getters and setters on it to setup the mojo or make use of the Ple= xusConfiguration step that lets an xml snippet on disk configuration everyt= hing for you.
This plugin harness is not the be all end all solution to mojo testing. = It does not do integration testing and the primary scope of the harness is= to provide a way for plugin authors to create a fully populated instance o= f their mojo only with stubs in the place of critical maven classes. This = is an attempt to all for some level of mojo testing without needing a full = fledged maven execution environment.
The first step is to make a test case in src/test/java and extend the Ab= stractMojoTestCase class. You must make sure that your setUp() me= thod called the super.setUp() otherwise looking up your components will fai= l. Then to get your mojo it is a simple matter of looking up the mojo and = passing in the configuration plugin pom.
This a sample plugin configuration file. If custom expressions are need= ed then we can add them to the StubResolverExpressionEvaluator class in the= plugin harness so things like the
above are taken care of. Notice the projectArtifact element a= bove with the implementation=3D"" attribute. This is how you wil= l inject the StubArtifact implementation into that projectArtifact private = variable on the mojo. Additional elements can be inserted as child element= s and they will in turn be assigned to the variables inside that object. A= n example would be setting the groupId variable on the StubMavenProject. N= ote: these internal variable might also need implementation=3D"" = attributes.
There is another way to use the harness if the above solution isn't desi= red, but it is a bit more dangerous perhaps and requires pretty good legwor= k 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.
This should allow you to populate most, if not all of the mojo as you ne= ed, depending on the depth to which it needs to be configured. Here is an = example on how it could be used.
Or I would even be used in conjuction with the above mechanism to tweak = a value.
Great care should be taken in the writing of tests using the approach si= nce there are none of the safeguards in place that plexus provides for this= sort of variable injection. However, this should help us in sticky situat= ions were we need to change/set the value of a variable in an object that m= ight 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.<= /p>
There are a couple of utility methods on the AbstractMojoTestCase that s= hould make the asserts easier to work with.
These two methods wrap functionality in the ReflectionUtils class in ple= xus utils that will let you retrieve the value of variable on the mojo. Si= nce most of the mojo's variables are private scope and most mojo's don't ma= ke use of getters and setters this will let you assert things about the int= ernal state of the mojo. Both methods return objects that need to be caste= d to what you want to look at, and as testers of the mojo in question it sh= ould be perfectly fine to just cast away based on your knowledge of the moj= o internals.
For example if I needed to check the value of the groupId in the project= instance in a given mojo this is what I would do.
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 config= uration and the other in the assert clauses) that it is very easy to get th= em 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 a= bsolute right thing then your assert will be working when the test itself m= ight have failed. So make sure you check these conditions, perhaps even as= serting 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 s= et and get variables in the instantiated mojo from the java side of the fen= ce------=_Part_3545_401574974.1369385853899--