3

I've been testing my business logic in ServiceStack 3.9.38 project, and faced a problem when running unit tests separatly leads to success, and running tests all together leads to fail of one of them. After several hours I've made a reproducible unit test. If you run the whole fixture, the second test will fail. Running tests separatly makes them pass.

using Funq;
using NUnit.Framework;

[TestFixture]
public class Test
{
    interface IBar {}
    class Bar : IBar {}
    class TestFoo { public IBar Bar { get; set; } }

    [Test]
    public void Test1()
    {
        var container = new Container();
        var m = new TestFoo();
        container.Register<IBar>(new Bar());
        Assert.NotNull(container.Resolve<IBar>(), "Resolve");
        container.AutoWire(m);
        Assert.NotNull(m.Bar, "Autowire");
    }

    [Test]
    public void Test2()
    {
        var container = new Container();
        var m = new TestFoo();
        container.AutoWire(m);
        Assert.Throws<ResolutionException>(() => container.Resolve<IBar>());
        Assert.IsNull(m.Bar); // FAILS HERE
    }
}

Is that an issue of Funq.Container configuration? Or this is a bug? Any workarounds?

EDIT: I've posted an issue on GitHub: https://github.com/ServiceStack/ServiceStack/issues/521

Pavel Kudinov
  • 405
  • 2
  • 8

1 Answers1

3

There is a private static dictionary autoWireCache at AutoWireHelpers.cs that is caching your resolutions When you run the test them twice the value is pulled from the cache and your test fails. I believe the caching is a feature of ServiceStack's customized funq for performance gains.

There is no public interface for clearing that cache so I see no quick solution to the way you have the tests setup.

kampsj
  • 3,139
  • 5
  • 34
  • 56
  • Oh yes, I knew that it was static somewhere... But it is realy not a good place for it! I think it should be Container instance specific... So the solution could be to make AutoWireHelpers class not static, autoWireCache not static, and make this class be a field of Container. But this is an in-core refactoring, so we should listen to @mythz – Pavel Kudinov Mar 15 '13 at 17:52
  • 2
    @PavelKudinov this issue has now been resolved and is no longer using static methods. – mythz Mar 19 '13 at 14:17