Screenshots and Artifacts
Screenshots can be a useful tool in debugging broken scripts as they will show you when a spinner is stuck spinning or a bit of ‘3rd party crap’ isn’t downloading properly. Both Py.Saunter and Saunter.PHP have some helper methods in their TestCase class to capture these.
Py.Saunter
<pre lang="python">self.take_named_screenshot('some name')
self.take_numbered_screenshot()
SaunterPHP
<pre lang="php">$this->take_named_screenshot('some name');
$this->take_numbered_screenshot();
Some notes on usage:
- The name of the screenshot does not need to have .png to it, that is added for you
- The numbered screenshot begins are 0001 and increments from there
- The number resets on each test method
- This is in the SaunterTestCase inheriting classes, not the Page Object. This is not by accident.
Screenshots and anything else generated by the script are broadly categorized as ‘artifacts’. Each script’s artifacts are stored in its own directory
- logs
- 2013-05-09-11-53-37
- TestClass
- TestMethod
- TestClass
- 2013-05-09-11-53-37
Cadging an idea from Sauce Labs, the final screen of the browser is captured as ‘final.png’ in there. Right now, there is not a flag for disabling this, but will be in a couple releases. As will automatic capturing on exceptions.
If you are using Jenkins as your CI server, there is an extra treat for your reporting with these new screenshotting methods. If Saunter knows that you are using Jenkins it will format the XML log that you use to integrate with Jenkins in such a way that the screenshots are available in the visual log when you drill down to the method. This is done via the JUnit Attachments plugin.
The configuration for this is just a single line in the appropriate config file.
Py.Saunter
<pre lang="python">[Saunter]
jenkins: true
SaunterPHP
<pre lang="php">$GLOBALS['settings']['saunter.ci'] = 'jenkins';