Changes for page Testing

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-xwiki:XWiki.VincentMassol
	1	+xwiki:XWiki.surli

Content

...	...	@@ -142,6 +142,30 @@
142	142	* Tests must not depend on one another. In other words, it should be possible to execute tests in any order and running only one test class should work fine.
143	143	* Tests that need to change existing configuration (e.g. change the default language, set specific rights, etc) must put back the configuration as it was. This is true only in flavor tests or when several functional tests of different domains are executed one after another. However functional tests located in xwiki-platform specific modules are only running the tests for their module and thus it's not important, and saves times, if they don't clean up.
144	144	* Tests are allowed to create new documents and don't need to remove them at the end of the test.
	145	+* Stdout/stderr validation errors(((
	146	+We have a [[check>>Community.Building.WebHome||anchor="HAutomaticChecks"]] that verifies if functional tests output some invalid content to stdout/stderr. If your test contains such errors it'll fail and then you have 3 options:
	147	+* It's a normal and expected output from the test (for ex the test verifies an error condition and it's expected it will raise a stack trace in the console). In this case add an expectation in the test. For example:(((
	148	+{{code language='java'}}
	149	+public class TemplateTest extends AbstractTest
	150	+{
	151	+ public void wrongTemplate()
	152	+ {
	153	+ ...
	154	+ this.validateConsole.getLogCaptureConfiguration().registerExpected( "Possible break-in attempt!",
	155	+ "Error getting resource [null]");
	156	+ }
	157	+...
	158	+{{/code}}
	159	+)))
	160	+* It's a non-expected error. You then have 2 sub-choices:
	161	+** Fix the problem (the best and recommended solution!)
	162	+** Increase the technical debt by adding an exclude. For example:(((
	163	+{{code language='java'}}
	164	+this.validateConsole.getLogCaptureConfiguration().registerExcludes(
	165	+ "java.lang.IllegalStateException: Response is committed");
	166	+{{/code}}
	167	+)))
	168	+)))
145	145
146	146	Examples of functional tests:
147	147
...	...	@@ -180,6 +180,15 @@
180	180	11. Depending on how you are starting the functional tests, you`d have to either add the system property in your maven build (surefire plugin configuration) or in your IDE (run configuration)
181	181	11. Read [[Selenium's FirefoxDriver documentation>>https://code.google.com/p/selenium/wiki/FirefoxDriver]] for more information and options
182	182
	207	+=== Adding a new maven dependency for minimal war ===
	208	+
	209	+All our functional testing are linked to the build of a custom instance of XWiki based on the dependencies contained in the pom.xml of the test.
	210	+However, those dependencies are added to a minimal war that is built using dependencies located on different places dependending if it is a docker test, or an older functional test.
	211	+
	212	+So when a new Maven dependency is added for all distributions, it should be declared in three places:
	213	+ * in {{code}}xwiki-platform-minimaldependencies/pom.xml{{/code}}: this will allow the dependency to be retrieved for both docker tests, and for the standard distribution
	214	+ * in {{code}}xwiki-tools-packager-plugin{{/code}}, in both {{code}}pom.xml{{/code}} and {{code}}PackageMojo.java{{/code}}: those are used for older functional tests.
	215	+
183	183	= XHTML, CSS & WCAG Validations =
184	184
185	185	* We are using JUnit to validate that all XWiki pages produce valid XHTML.