[1.x only] Can't access fixture data when using IUseFixture

[JCBrown]

I'm new to BDD and xBehave but I'm already a convert!
I'm currently trying to write an integration test to test my code against a closed-source host application, I'm using a fixture which starts everything up and then shuts down gracefully when disposed, the fixture works fine for Facts and Theories but when I try to write a Scenario it seems to be started and stopped several times but is never actually available when a Scenario runs.

The following Fact HostExistsForFacts passes but the Scenario HostExistsForScenario fails.

using System;   //V4.0.0.0
using FluentAssertions; //V2.0.1.0
using Xbehave;  // V0.15.0.0
using Xunit;    // V1.9.1.1600

namespace MyNamespace
{
    public class FixtureXBehaveTest : IUseFixture<AnApplicationHost>
    {
        public void SetFixture(AnApplicationHost data)
        {
            this.Host = data;
        }

        private AnApplicationHost Host { get; set; }

        [Fact]
        public void HostExistsForFacts()
        {
            this.Host.Should().NotBeNull();
            this.Host.Application.Should().NotBeNull();
        }

        [Scenario]
        public void HostExistsForScenario()
        {
            AnApplicationHost fixture = null;
            "Given the Tests Fixture"
                .Given(() => fixture = this.Host);

            "Then it should exist"
                .Then(() => fixture.Should().NotBeNull());

            "and have an accessible Application"
                .And(() => fixture.Application.Should().NotBeNull());
        }
    }

    public class AnApplicationHost : IDisposable
    {
        public AnApplicationHost()
        {
            Application = new object();
        }

        public object Application { get; private set; }

        public void Dispose()
        {
        }
    }
}

I'm using the xUnitContrib 1.2 runner for ReSharper 7.1 with VS2012 U2.

[adamralph]

Hi JC. When I think about the life cycle of the objects and the emission of the test commands, whilst not obvious, the behaviour you're observing makes sense. I guess this demonstrates an incompatibility between xUnit.net's IUseFixture (not something I use) and xBehave.net. This may be solvable, but in the meantime I suggest you investigate using xBehave.net's Background attribute together with .Teardown() instead. See http://adamral.ph/2012/07/28/new-background-attribute-in-xbehave-net-0-12-0/.

I'm travelling right now, but I can investigate the IUseFixture compatibility when I'm home in a few weeks, if it turns out to add value over and above Background attribute.

[JCBrown]

Adam,
I looked at the Background steps attribute and it led me to a solution with the behaviour I was looking for.
I didn't actually use background steps but noticing the static methods in your example I realised I just needed to alter the test classes property storing my fixture instance to static; it initially felt like a cheat but all things considered it seems to make sense.
As documented the test-runner simply supplies a single instance to all calls of SetFixture for a given Fixture type. Given there's only a single instance of the fixture being maintained then there's little harm my test class holding on to that reference (and I suppose if I was worried about GC then a WeakReference backing field could be used).

Thanks for you input and I hope your trip is going well.

James

[adamralph]

Ah it's great to hear that. Is it OK to close the issue in that case?

[JCBrown]

It's fine to close the issue but do you think this should be documented anywhere?
I was toying with the idea of adding something to the wiki myself but I didn't want to spoil the zen of the ToC.

James

[adamralph]

OK, after re-reading your workaround I now see exactly what's happening. xBehave maintains it's own instances of test classes for test method invocation and these are separate from the ones that xUnit creates and invokes SetFixture() on. This means there definitely is a disconnect between the workings of xUnit and xBehave. I can see why your workaround works, but it's quite ugly to have to do that, i.e. an instance member modifying static state.

I think it's better we leave this issue open and investigate a solution which removes the need to have static state. In the meantime feel free to edit the wiki - I'm not attached to its voluminous layout in any way 😉.

[adamralph]

Moved to Ready. The bug is clearly understood and should be addressed.

[adamralph]

https://twitter.com/adamralph/status/393661051348086784

[adamralph]

@JCBrown I finally documented the workaround after @domgreen raised the same problem over in #18. See https://github.com/xbehave/xbehave.net/wiki/Known-Issues.

Of course, I really should just fix the bug 😬.

[JCBrown]

Thanks @adamralph, I really should have made my mark on that empty Wiki ;-) it's really come on now, just having a little read.
I'm using Xbehave regularly now, finding it helps me keep focus on the real requirements rather than loose myself in the detail.

[adamralph]

Glad you like the wiki, it's surprising what can be done on one rainy Sunday 😉.

It's great that you're finding xBehave so useful, hearing that makes it worthwhile.

[adamralph]

IUseFixture has been removed in xunit 2.0 and therefore xbehave 2.0 has no need to support it.

xbehave 2.0 is currently in RC (https://www.nuget.org/packages/Xbehave/2.0.0-rc002-build543).

This will remain as a bug in 1.x, unless someone can sell me a very compelling reason why they need to stick to 1.x and why they need this to be fixed 😉.