nunit-core team mailing list archive

[Charlie Poole <charlie@xxxxxxxxx>]

Hi Robert,

Actually, we have not rejected the idea of ordering. Rather - as shown
by the new vision statement you quote -
we are embracing it for the new NUnit. For that reason, I'm moving
your report to that project.

It may not be quite as simple as adding a single attribute, since we
don't want to use the existing unit test-focused
TestFixture to represent ordered sets of tests. However, we can
discuss details of how it will be implemented on the
nunit-discuss list.

(BTW, I'm not able to find a bug with ID 878856)

Charlie

On Tue, Mar 22, 2011 at 3:22 PM, Robert Sosnowski
<740539@xxxxxxxxxxxxxxxxxx> wrote:
> Public bug reported:
>
> I'm aware that in the past similar request were rejected (for example ID: 878856). However I'll try once again giving some rationale for this.
> Here: http://www.nunit.org/wiki/doku.php?id=dev:vision it is clearly stated: "support use of NUnit for integration and acceptance testing, but only to the extent that this support didn't interfere with our primary goal"
> Even if this would not be written all we know that NUnit is not only used for unit testing but for all kinds of automatic testing, for example running web pages (Selenium), WinForms (project White), and many other purposes.
> In general creating full setup in integration test scenario is costly. Other reason: http://stackoverflow.com/questions/1078658/nunit-test-run-order/2889524#2889524. Also good justification here: http://aspadvice.com/blogs/ssmith/archive/2005/04/12/1858.aspx
> In my particular test I have an integration with database: test if account creates, then if address for this account creates, then test if payment for this account suceeds, then ... (very long user case chain). While it is possible to create independent tests it is difficult to do, causes code repetition and slows down testing.
> Adding additional ordering attribute should not break primary goal: pure unit testing can be still possible when not using this special attribute.
> It seems for me that such an attribute would not be costly in implementation effort. Especially in comparison with other sophisticated NUnit functionality.
>
> ** Affects: nunitv2
>     Importance: Undecided
>         Status: New
>
> --
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
> https://bugs.launchpad.net/bugs/740539
>
> Title:
>  Feature request: attrbiute for controlling of test order
>

-- 
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/740539

Title:
  Feature request: attrbiute for controlling of test order

Status in NUnit Test Framework:
  New

Bug description:
  I'm aware that in the past similar request were rejected (for example ID: 878856). However I'll try once again giving some rationale for this.
  Here: http://www.nunit.org/wiki/doku.php?id=dev:vision it is clearly stated: "support use of NUnit for integration and acceptance testing, but only to the extent that this support didn't interfere with our primary goal"
  Even if this would not be written all we know that NUnit is not only used for unit testing but for all kinds of automatic testing, for example running web pages (Selenium), WinForms (project White), and many other purposes.
  In general creating full setup in integration test scenario is costly. Other reason: http://stackoverflow.com/questions/1078658/nunit-test-run-order/2889524#2889524. Also good justification here: http://aspadvice.com/blogs/ssmith/archive/2005/04/12/1858.aspx
  In my particular test I have an integration with database: test if account creates, then if address for this account creates, then test if payment for this account suceeds, then ... (very long user case chain). While it is possible to create independent tests it is difficult to do, causes code repetition and slows down testing.
  Adding additional ordering attribute should not break primary goal: pure unit testing can be still possible when not using this special attribute.
  It seems for me that such an attribute would not be costly in implementation effort. Especially in comparison with other sophisticated NUnit functionality.