Hi Eric,
Taking screenshot on failure, is normally done automatically.
Taking a screenshot when you want, for example just before clicking on
a button is easy.
We have this small api, which allow us to create screenshot. Just
change the myPath part for your project. The parameter you give is the
image name. In case you want to take several screen shot during tests.
public static void doScreenShot(String imgName) {
File currentFolder = new File("myPath");
ScreenshotTaker screenshotTaker = new ScreenshotTaker();
File imageFolder = new File(currentFolder.getAbsolutePath(),
"failed-tests");
if (!imageFolder.exists()) {
imageFolder.mkdirs();
}
File tmpFile = new File(imageFolder.getAbsolutePath(),
imgName);
if (tmpFile.exists()) {
tmpFile.delete();
}
screenshotTaker.saveDesktopAsPng(tmpFile.getAbsolutePath());
}
Hope this help,
Olivier
On Jun 9, 4:06 pm, Eric Kolotyluk <
e...@sfu.ca> wrote:
> The build agent is running under a user account.
> We are using Windows XP SP3.
> We are using FEST-Swing 1.2a2
> I'll have to figure out how to take a screenshot on failure - I hope it's not hard to set up.
> Cheers, Eric
> Peter Murray wrote:What user is the TeamCity buildagent running under? Local System or a user account? What version of Windows are you using?
> To get all FEST Swing tests to pass under TeamCity for us we needed to run the build agent service under a user account on Windows (and not a domain user account). We have only ever successfully managed to get TeamCity buildagents running as a service and passing FEST Swing tests on Windows XP, later versions of windows force services to use another desktop, not the actual users desktop, due to security concerns and this causes focus problems (among other things).
> Another important thing is to disable the screensaver and automatic locking of the PC when left unattended as this has caused us problems in the past.
> As an aside, it might be worth taking a screenshot from within your tests upon failure and adding the screenshot(s) to the build artifacts in TeamCity as these are invaluable when trying to understand failures from the TeamCity build agents (most of the time things are not as they seem, or you think they should be).
> - PeterOn Mon, Jun 8, 2009 at 7:38 PM, Eric Kolotyluk<
er...@sfu.ca>wrote:So we've learned a bit more, but still have no solution.
> We have noticed that there seem to be focus problems when the unit test is running - in particular if the user clicks the mouse in different windows (presumably stealing focus) we can get the test to timeout the same way as it fails when running under a TeamCity build agent. We suspect there is some sort of focus problems when running under the build agent, but we can't imagine what. We've sent e-mail to the JetBrains TeamCity list to see if anyone else there knows.
> My question to the FEST community is has any one else has similar problems when running FEST tests under build agents?
> What is equally strange is that our logs show the test passed on two occasions when running under TeamCity - and we don't know why. We have also noticed that the tests take a lot longer when running under TeamCity (> 10 seconds) but are fast when run live (~ 1 second). If I increase the timeout on the failing test, the test runs longer (> 20 seconds) and times out anyway.
> Below is the source of the test that is failing under TeamCity
> Cheers, Eric
> @Test
> public void isVisible() // This test always succeeds
> {
> dialogFixture.requireVisible();
> }
> @Test
> public void isNameEmptyErrorMessageDisplayed() // Fails most of the time under TeamCity
> {
> dialogFixture.button("okButton").click();
> JOptionPaneFixture optionPane = dialogFixture.optionPane();
> //JOptionPaneFixture optionPane = dialogFixture.optionPane(Timeout.timeout(10000));
> optionPane.requireErrorMessage();
> optionPane.requireTitle(Messages.getString("title.DataEntryError"));
> optionPane.requireMessage(Messages.getString("NotificationManager.message.TheRecipientNameFieldIsBlank"));
> }
> ----- Original Message -----
> From: "Eric Kolotyluk" <
er...@sfu.ca>
>
To:easyt...@googlegroups.com
>
> Sent: Monday, June 8, 2009 8:05:06 AM GMT -08:00 US/Canada Pacific
> Subject: [easytesting] Re: Timing Problems with optionPane.requireMessage()So I noticed the default timeout was 100 ms. I increased the timeout to 1 second, same problem. I increased the timeout to 10 seconds, same problem. I suspect something else is at play here.
> Any more ideas of something to try?
> Cheers, Eric
> ----- Original Message -----
> From: "Alex Ruiz" <
alex.r...@gmail.com>
>
To:easyt...@googlegroups.com
> Sent: Friday, June 5, 2009 10:58:14 AM GMT -08:00 US/Canada Pacific
> Subject: [easytesting] Re: Timing Problems with optionPane.requireMessage()
> Hi Eric,
> It seems to be a timing issue. If you are using the latest release (1.2a2), there is an overloaded verstion of 'optionPane' in ContainerFixture that takes a timeout. Please give it a try and let me know if that helped.
> Cheers,
> -AlexOn Thu, Jun 4, 2009 at 3:31 PM, Eric Kolotyluk<
er...@sfu.ca>wrote:I have a test that calls OptionPane.requireMessage(). On my desktop the test always works fine. But on our build machine sometimes the test fails because
>
> [junit] Testcase: isNameEmptyErrorMessageDisplayed took 1.093 sec
>
> [junit] Caused an ERROR
>
> [junit] Timed out waiting for option pane to be found using matcher org.fest
>
> .swing.core.TypeMatcher[type=javax.swing.JOptionPane, requireShowing=true]
>
> [junit] org.fest.swing.exception.WaitTimedOutError: Timed out waiting for op
>
> tion pane to be found using matcher org.fest.swing.core.TypeMatcher[type=javax.s
>
> wing.JOptionPane, requireShowing=true]
>
> [junit] at org.fest.swing.timing.Pause.pause(Pause.java:74)
>
> [junit] at org.fest.swing.timing.Pause.pause(Pause.java:58)
>
> [junit] at org.fest.swing.fixture.ContainerFixture.optionPane(ContainerF
>
> ixture.java:264)
>
> [junit] at org.fest.swing.fixture.ContainerFixture.optionPane(ContainerF
>
> ixture.java:256)
>
> [junit]
atcom.kodak.kps.notificationManager.RecipientEditorUnitTests.is
>
> ...
>
> read more »