Attribute "Repeat" in NUnit v3.0

97 views
Skip to first unread message

constructor

unread,
Mar 16, 2015, 7:12:09 AM3/16/15
to nunit-...@googlegroups.com
Hi,

Attribute "Repeat" cannot be compiled with NUnit v3.0.
Page Breaking Changes (http://nunit.org/index.php?p=breakingChanges&r=3.0) doesn't contain any information about attribute Repeat.

Please, could you add to "Breaking Changes" how to change "Repeat"?

thank you,
Igor.

Rob Prouse

unread,
Mar 16, 2015, 9:13:55 AM3/16/15
to nunit-...@googlegroups.com
Igor,

The Repeat attribute is currently commented out in NUnit 3, but we will likely implement it. See issue #478 at https://github.com/nunit/nunit/issues/478.

That said, the Repeat attribute is a bit of an anti-pattern. Tests should deterministicly pass or fail with just one run. I find that if tests randomly fail, developers stop taking the test results seriously and because of that, don't take the tests themselves seriously.

That is my experience though, not yours. Can you tell us why and how you use the Repeat attribute so we can prioritize the issue?

Rob

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nunit-discus...@googlegroups.com.
To post to this group, send email to nunit-...@googlegroups.com.
Visit this group at http://groups.google.com/group/nunit-discuss.
For more options, visit https://groups.google.com/d/optout.



--

Rob Prouse

 

I welcome VSRE emails. Learn more at http://vsre.info/

constructor

unread,
Mar 16, 2015, 11:06:08 AM3/16/15
to nunit-...@googlegroups.com
Rob,
first of all, thank you for fast and detailed answer.

We use attribute "Repeat" in next cases:

1. Bug reproducing (multi-threaded) issue. 
To reproduce a bug, developer implements test. Sometimes (when the bug related to multi-threaded issue) we need execute the test many times to reproduce the bug. When bug reproduced, developer fixes found problem and execute the test again (with Repeat) to check implemented fix.

2. Search "failed" input data for random failed test.
A test generates random input for tested code and sometimes fails. To found the input data we execute test with attribute Repeat. When the concrete input found, we add relevant test and delete "Repeat" from original test.

3. Testing "multi-threaded" code.
To be sure if a concrete code works in multi-threaded (multi-process) mode, I implement test and permanently execute the test with Repeat(<enough big number>).

I found several attributes "Repeat" only in our tests and, sure, we can change it without any problems to some "loop" implementation inside test.
Probably, could you add status of "Repeat" to page Breaking Changes (http://nunit.org/index.php?p=breakingChanges&r=3.0). It will help to other developers.

Also, probably, could you suggest other ways to support scenario where today developers use "Repeat".

Igor.

Rob Prouse

unread,
Mar 16, 2015, 11:14:13 AM3/16/15
to nunit-...@googlegroups.com
Igor,

I added your use cases to the issue, thank you.

We will update the breaking changes page once we decide if the Repeat attribute will be removed. If it is not removed, it will be done before the final 3.0 release.

For your third point, we are also considering a ThreadedRepeat attribute which work like Repeat except that all tests are run at the same time rather than sequentially.

rob
Reply all
Reply to author
Forward
0 new messages