Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<h1>Testing Strategies</h1>

<p>Currently, Maven only supports unit testing out of the box. What we want is something flexible enough to work without having to make test definitions arbitrary.</p>

<h2>Types of Tests</h2>

<h3>Unit Tests</h3>

<ul class="alternate">
	<li>run before package</li>
	<li>want 100% success before moving on generally</li>
</ul>

<h3>Integration Tests</h3>

<ul class="alternate">
	<li>require the artifact, so run after package but before install.</li>
	<li>generally want 100% before moving on.</li>
	<li>May use junit or other plugin like cactus, including deploying to a server</li>
</ul>

<h3>Acceptance Tests</h3>

<ul class="alternate">
	<li>also called functional or regression tests.</li>
	<li>not run every time, probably a report and/or part of a profile.</li>
	<li>run after install, before deploy</li>
	<li>Regression tests (acceptance tests from previous milestones) should be at 100%</li>
	<li>acceptance (also called functional) tests only need to get to 100% at release time.</li>
	<li>performance/stress tests - another form of acceptance test.</li>
</ul>

<h2>Use cases</h2>

<ul class="alternate">
	<li>plugin integration tests (c.f. eclipse plugin)</li>
	<li>report integration tests (see Vincent S's work - htmlunit)</li>
	<li>cactus plugin</li>
	<li>geronimo itest plugin</li>
	<li>need to be able to compile additional sources, have own dependencies (basically reapply the whole test lifecycle again - given that this also matches the main one, perhaps that can be reusable/forked)</li>
	<li>we should have a setup and teardown phase around the actual test goal</li>
	<li>may want to reapply test stuff on other test sets (eg junit report, clover)</li>
</ul>

<p>separate project is ideal, but</p>
<ul class="alternate">
	<li>a bit unnatural, more strung out</li>
	<li>doesn't fit IDE well</li>
	<li>you can still use it if you support in project tests, so better to do that</li>
</ul>

<p>While a separate project might be something we recommend, I think we need to support them within the same project.</p>

<h2>Design</h2>

<h3>Plugin integration tests</h3>

<p>This means running a separate instance of Maven to do it effectively, so should always be separate projects utilising the built archive without requiring it be installed (bound to the integration test phase).</p>

<p><img class="emoticon emoticon-question" data-emoticon-name="question" border="0" src="/s/en_GB/3278/15/_/images/icons/emoticons/help_16.png" alt="(question)" title="(question)" /> How can we ensure the integration test of the subproject is run before installation of the parent?<br />
<img class="emoticon emoticon-information" data-emoticon-name="information" border="0" src="/s/en_GB/3278/15/_/images/icons/emoticons/information.png" alt="(info)" title="(info)" /> Perhaps it is better to have a plugin integration testing plugin that actually runs from the parent and execs maven on the subproject.</p>

<h3>Report integration tests</h3>

<p>This should be done in an identical fashion to a plugin integration test, but using htmlunit to test the output. This means having junit test cases.</p>

<h3>Junit Integration Tests</h3>

<table class="wysiwyg-macro" data-macro-name="info" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2luZm99&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="RICH_TEXT"><tr><td class="wysiwyg-macro-body">
<p>We have an issue here in that we would have to recofigure the whole plugin, essentially needing to know its information. Can we preconfigure it, like we do with the forked lifecycles? Or is it best to just wire this one in by default to the integration testing parts of the lifecycle and use a different mojo (surefire:itest, compiler:itestCompile)?</p></td></tr></table>

<h3>Cactus Plugin</h3>

<h3>Junit Acceptance Tests</h3>

<p>These would be set up in the same way as the junit integration tests except for the time at which they are run. The main difference may be that the default configuration would be to change the required acceptance to pass. It may be better to have a different plugin for these in general, but the default would also be surefire like above.</p>

<h3>Reapplying junit report/clover to other test sets</h3>

<h2>Resources</h2>

<ul>
	<li>maven-it-plugin in the sandbox</li>
	<li>Discussion threads on Maven mailing list on the testing strategy
	<ul>
		<li><a class="external-link" href="http://www.nabble.com/Packaging-type-for-functional-integration-test-projects--t469087.html#a1278258" rel="nofollow">http://www.nabble.com/Packaging-type-for-functional-integration-test-projects--t469087.html#a1278258</a></li>
	</ul>
	</li>
	<li>Related Article <a class="confluence-link" href="/display/MAVEN/best+practices+-+testing+strategies" data-linked-resource-id="37021" data-linked-resource-type="page" data-linked-resource-default-alias="best practices - testing strategies" data-base-url="http://docs.codehaus.org">Best Practices - Testing Strategies</a></li>
</ul>