One-time setup/teardown for a group of fixtures.

[Rastislav Galia]

Hi, I am new to both NUnit and NUnitLite, so please have some patience, if I ask the obvious. Anyway, I would like to ask you: how do I instruct NUnitLite to perform specific one-time setup/teardown code, that is common to a prticular group of fixtures. The "big" NUnit has two mechanisms (SetUpFixture and Suite) that can be utilized to that end. What is the Lite's way of doing it ?

/Rastislav Galia

[Charlie Poole]

NUnitLite doesn't support either of those alternatives. In the case of
the SuiteAttribute, it's fairly old and it may not be supported in
future releases of NUnit.
SetUpFixtureAttribute will eventually be supported in NUnitLite, but
it's not in any current releases, including the current Beta.

Absent SetUpFixture, the best way to perform common initialization is
using inheritance. Put the common setup/teardown in a
TestFixtureSetUp/TestFixtureTearDown method in the base class. If you
want it to be executed once per fixture, that's all you have to do. If
you want to have onetime setup and teardown, it's a bit more
complicated.

For setup, use a static flag to indicate whether the setup has been
performed in this run. If it has been performed once, then don't
execute your code.

Teardown is harder. Try to avoid one time teardown until we have a
SetUpFixture. The hack to do it is to have each one time setup
increment a static (!) counter. Your onetime teardown should decrement
the counter and only execute its code when it reaches zero. Best to
avoid this, however.

SetUpFixture will be supported in the version of NUnitLite that comes
out with NUnit 3.0, expected around year end.

Charlie

> --
> You received this message because you are subscribed to the Google Groups
> "NUnitLite" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nunitlite+...@googlegroups.com.
> To post to this group, send email to nuni...@googlegroups.com.
> Visit this group at http://groups.google.com/group/nunitlite.
> For more options, visit https://groups.google.com/groups/opt_out.

[Rastislav Galia]

thank you for your response ! I didn't really grasp the counter trick. I waNUnitLitendNUnitLiteer the impression that steps "setup/execution/teardown" are repeated in an alternating fashion for each fixture in a group. But your counter trick requires that all the setup routines are finished before the first teardown is started.

I may opt for implementing the SetUpFixture feature myself. By the way, is NNUnitLite open to code contributions ?

[Charlie Poole]

Hi,

Your message is garbled but I think you meant "I was under the impression"

For a single fixture with a base class, the sequence is

Base TestFixtureSetUp
Derived TestFixtureSetUp
SetUp
Test #1
TearDown
SetUp
Test #2
TearDown
...
Derived TestFixtureTearDown
Base TestFixtureTearDown

So, as you understood, the base setup is executed multiple times. In
order to get a base setup that executes only once, write something
like this in the base class...

static int numSetups = 0;

[TestFixtureSetUp]
public void SimulatedOneTimeSetUp()
{
if (numSetups++ == 0)
{
// Your Setup code
}
}

[TestFixtureTearDown]
public void SimulatedOneTimeTearDown()
{
if (--numSetups == 0)
{
// Your TearDown code
}
}

Everyone: yes, I know this is a hack and rather fragile. But it's the
only way I know to get the desired result with NUnitLite!

Like all the NUnit projects, NUnitLite is Open Source and open to
contributions. We're now at Beta 2 of NUnitLite 1.0 and will shortly
release the final version. Further development will be as a part of
NUnit 3.0, with the code for NUnit and NUnitLite now being shared.
SetUpFixture is already implemented in that code, but it isn't yet
quite ready for release.

We'd be glad to have you work on some part of NUnit 3.0.

Charlie

On Wed, Sep 4, 2013 at 2:50 PM, Rastislav Galia <racho...@gmail.com> wrote:
> thank you for your response ! I didn't really grasp the counter trick. I waNUnitLitendNUnitLiteer the impression that steps "setup/execution/teardown" are repeated in an alternating fashion for each fixture in a group. But your counter trick requires that all the setup routines are finished before the first teardown is started.
>
> I may opt for implementing the SetUpFixture feature myself. By the way, is NNUnitLite open to code contributions ?
>

[Rastislav Galia]

Dňa štvrtok, 5. septembra 2013 0:07:25 UTC+2 charlie napísal(-a):

Hi,

Your message is garbled but I think you meant "I was under the impression"

 

Sorry for the garbling, it was most likely caused by the mobile version of Groups web interface (I was typing my reply on Android). BTW, sorry for my poor English, Central-Easter Europe here.
 

For a single fixture with a base class, the sequence is

Base TestFixtureSetUp
Derived TestFixtureSetUp
SetUp
Test #1
TearDown
SetUp
Test #2
TearDown
...
Derived TestFixtureTearDown
Base TestFixtureTearDown

My point was: having two test fixtures TestFixture1 and TestFixture2, both derived from BaseTestFixture, there are two possible calling sequence alternatives:
 
1,

BaseTestFixture.TestFixtureSetUp + TestFixture1.TestFixtureSetUp
<<foreach (test in TestFixture1) { setup/test/teardown } >>
TestFixture1.TestFixtureTearDown + BaseTestFixture.TestFixtureTearDown

BaseTestFixture.TestFixtureSetUp + TestFixture2.TestFixtureSetUp
<<foreach (test in TestFixture2) { setup/test/teardown } >>
TestFixture2.TestFixtureTearDown + BaseTestFixture.TestFixtureTearDown

2,

BaseTestFixture.TestFixtureSetUp + TestFixture1.TestFixtureSetUp
BaseTestFixture.TestFixtureSetUp + TestFixture2.TestFixtureSetUp

<<foreach (test in TestFixture1) { setup/test/teardown } >>
<<foreach (test in TestFixture2) { setup/test/teardown } >>

TestFixture1.TestFixtureTearDown + BaseTestFixture.TestFixtureTearDown
TestFixture2.TestFixtureTearDown + BaseTestFixture.TestFixtureTearDown

---

The "counter" trick will of course work only if the second alternative is used. In case of the first scheme the counter value would never get past 1, resulting in each-time (as opposed to one-time) behavior.

We'd be glad to have you work on some part of NUnit 3.0.

Can you give me some pointers to development commnity resources ?

/ Rastislav Galia

[Charlie Poole]

The sequence is #1 and you are correct that my counter won't work as
specified. More exactly, it won't work for teardown, which will
execute prematurely. If you have teardown, it will only work if you
know in advance how many classes are using the setup, which is a
really bad hack.

static bool ranSetup;
static int numSetups = 2; // for example

[TestFixtureSetUp]
public void SimulatedOneTimeSetUp()
{
if (!ranSetup)
{
// Your Setup code

ranSetup = true;

}
}

[TestFixtureTearDown]
public void SimulatedOneTimeTearDown()
{
if (--numSetups == 0)
{
// Your TearDown code
}
}

Two notes:
1. The TestFixtures may run in any order.
2. Unrelated tests may run between the related TestFixtures, so no
hack will work if there are other fixtures that change the environment
you set up for TestFixture1 and TestFixture2.

As an option, if this is a major issue for you, you could consider
using the unreleased nunitlite 3.0 code. Currently, you would have to
build it from source.

Charlie

Charlie

[Rastislav Galia]

Hi

I decided to try to port SetUpFixtureBuilder and SetUpFixture classes into (my copy of) NUnitLite 1.0. I hope to make it work under NETCF_3_5.

Btw (unrelated to this feature), I also enabled the support for IEquatable<> classes in NUnitEqualityComparer with NETCF_3_5. That was another piece of functionality I missed dearly in Lite. Admittedly, this was a low-hanging fruit :-)

/Rastislav Galia

[Charlie Poole]

OK, sounds good. Here are a few pointers to help get started:

1. NUnitLite has the same architecture as NUnit 3.0 framework, so port
from that, not from NUnit 2.6.2, to make it easier on you.

2. In addition to the obvious (SetUpFixture, SetUpFixtureAttribute)
you should look at DefaultTestAssemblyBuilder (cf
NUnitLiteTestAssemblyBuilder), SuiteBuilderCollection,
SetUpFixtureBuilder and NamespaceTreeBuilder.

3. The implementation of SetUpFixture depends on the tests being
organized in a hierarchy. NUnitLite loads tests as a flat list of
fixtures, which is why you need to add NamespaceTreeBuilder.

4. I'm changing some Namespaces in NUnit 3.0, so you'll have to edit
those to conform with NUnitLite.

Good Luck!

Regarding IEquatable<>, that is also implemented in 3.0.

If you're modifying it anyway, maybe you want to start with the 3.0
source. NUnitLite 1.0 is a dead end as far as our current plans,
because it's too much effort to maintain two codebases. If you work
with NUnit 3.0, then your work could feed into both "big" NUnit and
NUnitLite and we would love to have your contributions!

Charlie