Timeout for configuration-methods

[Carsten]

Hi all,

is there any way to specify a timeout for configuration methods?

Thanks,
Carsten

[André Abe Vicente]

There are options in @Test anottation (invocationTimeOut and timeOut). 

@Test

Marks a class or a method as part of the test.

invocationTimeOut

The maximum number of milliseconds this test should take for the cumulated time of all the invocationcounts. This attribute will be ignored if invocationCount is not specified.

timeOut

The maximum number of milliseconds this test should take.

http://testng.org/doc/documentation-main.html

--
You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

[Tomek Kaczanowski]

> > is there any way to specify a timeout for configuration methods?

I have exactly the same problem. In set up methods sometimes you
invoke some database operations or other stuff that deals with remote
servers. It would be nice to be able to say:
@BeforeClass(invocationTimeOut = xyz)
and have the same behaviour as for @Test.

--
Regards,
Tomek Kaczanowski
http://kaczanowscy.pl/tomek

[Cédric Beust ♔]

Tomek, André,

I just added support for configuration time outs in the beta: you can now specify a timeOut attribute on all @Before* and @After* methods.

Could you give it a try and let me know how it works for you?  http://testng.org/beta

Thanks.

--
Cédric

--

You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[Tomek Kaczanowski]

Hello Cedric,

I tested testng-5.14.1beta.zip and it works fine.

The following test:

public class ConfigurationTimeoutTest {

@BeforeClass(timeOut = 2500)
public void beforeClass() throws InterruptedException {
while(true) { }
}

@Test
public void shouldBeSkipped() {
throw(new RuntimeException("should be skipped"));
}
}

gives the following result:

<testng-results>
<reporter-output>
</reporter-output>
<suite name="Gradle suite" duration-ms="2527" started-
at="2010-10-03T20:55:59Z" finished-at="2010-10-03T20:56:02Z">
<groups>
</groups>
<test name="Gradle test" duration-ms="2527" started-
at="2010-10-03T20:55:59Z" finished-at="2010-10-03T20:56:02Z">
<class
name="pl.kaczanowscy.tomek.testng.ConfigurationTimeoutTest">
<test-method status="FAIL" signature="beforeClass()"
name="beforeClass" is-config="true" duration-ms="0" started-
at="2010-10-03T20:55:59Z" finished-at="2010-10-03T20:55:59Z">
<exception
class="org.testng.internal.thread.ThreadTimeoutException">
<message>
<![CDATA[Method
org.testng.internal.ConfigurationMethod.beforeClass() didn't finish
within the time-out 2500]]>
</message>
<full-stacktrace>
<!
[CDATA[org.testng.internal.thread.ThreadTimeoutException: Method
org.testng.internal.ConfigurationMethod.beforeClass() didn't finish
within the time-out 2500
at java.util.concurrent.FutureTask
$Sync.innerSetException(FutureTask.java:273)
at java.util.concurrent.FutureTask
$Sync.innerRun(FutureTask.java:307)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
]]>
</full-stacktrace>
</exception>
</test-method>
<test-method status="SKIP" signature="shouldBeSkipped()"
name="shouldBeSkipped" duration-ms="1" started-
at="2010-10-03T20:56:02Z" finished-at="2010-10-03T20:56:02Z">
</test-method>
</class>
</test>
</suite>
</testng-results>

which seems fine for me.

One question thought. @Test uses invocationTimeOut and @BeforeClass
uses timeOut. I would suggest to use the same name for both test and
configuration methods.

[Cédric Beust ♔]

Hi Tomek,

Very good point, I forgot that it was called "invocationTimeOut" on @Test (and looking closer why I picked this name, it's to be consistent with "invocationCount").

I'll be changing the name of this attribute to "invocationTimeOut" to be consistent with @Test, be aware of this breaking change (not officially released yet, so not really breaking).

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "testng-users" group.
To post to this group, send email to testng...@googlegroups.com.
To unsubscribe from this group, send email to testng-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-users?hl=en.

--
Cédric

[Cédric Beust ♔]

Tomek,

Actually, I take that back :-)

There are two distinct time out attributes on @Test: "timeOut" is for the time out of a method and "invocationTimeOut" is used to cap the total running time of a method with more than one invocation (invocationCount > 1).

Therefore, the time out attribute on configuration methods will remain "timeOut".

Hope this makes sense.

-- 

Cédric

2010/10/4 Cédric Beust ♔ <ced...@beust.com>

--
Cédric

[Tomek Kaczanowski]

> There are two distinct time out attributes on @Test: "timeOut" is for the
> time out of a method and "invocationTimeOut" is used to cap the total
> running time of a method with more than one invocation (invocationCount >
> 1).

Wow, I was not aware of this and I always used "invocationTimeOut" -
silly me ;). In such case then of course it should be "timeOut".

[Cédric Beust ♔]

On Mon, Oct 4, 2010 at 11:53 PM, Tomek Kaczanowski <kaczanow...@gmail.com> wrote:

> There are two distinct time out attributes on @Test: "timeOut" is for the
> time out of a method and "invocationTimeOut" is used to cap the total
> running time of a method with more than one invocation (invocationCount >
> 1).

Wow, I was not aware of this and I always used "invocationTimeOut" -

The two attributes are equivalent when invocationCount = 1, so it's not surprising that your approach is working as well.

--
Cédric