From version 33.1
edited by Marius Dumitru Florea
on 2019/05/15 16:15
To version 34.1
edited by Vincent Massol
on 2019/05/21 09:32
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -xwiki:XWiki.mflorea
1 +xwiki:XWiki.VincentMassol
Content
... ... @@ -296,6 +296,28 @@
296 296  {{/code}}
297 297  )))
298 298  
299 +== Stdout/stderr validation errors ==
300 +
301 +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:
302 +* 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:(((
303 +{{code language='java'}}
304 +public void wrongTemplate(LogCaptureConfiguration logCaptureConfiguration)
305 +{
306 + ...
307 + logCaptureConfiguration.registerExpected( "Possible break-in attempt!",
308 + "Error getting resource [null]");
309 +}
310 +{{/code}}
311 +)))
312 +* It's a non-expected error. You then have 2 sub-choices:
313 +** Fix the problem (the best and recommended solution!)
314 +** Increase the technical debt by adding an exclude. For example:(((
315 +{{code language='java'}}
316 +logCaptureConfiguration.registerExcludes(
317 + "java.lang.IllegalStateException: Response is committed");
318 +{{/code}}
319 +)))
320 +
299 299  = Test Resources =
300 300  
301 301  You might need test resources to be used in interaction with the wiki (e.g. to upload an attachment). Any test resources placed in ##src/test/resources## is made automatically available to the browser container by mounting the dedicated volume mapped to ##target/test-classes##. Then, in your test, you can use the dedicated method to get access to the files located in ##target/test-classes##.

Get Connected