chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes
xUnit.net allows Test Methods to be async.

This allows easier testing (not mocking) of async code because you can use the await keyword inside the test.

However, this appears to break Typemock.

I believe this is because when you mark a method with the 'async' keyword, it generates a private, anonymous class named after the method. However this anonymous classes is not annotated with the [Isolated] attribute. This appears to cause tests to fail in various dramatic ways when Typemock is being used.

For example;

[Isolated]
public class TestClass
{
        private class FakedClass
        {
            public void FakedMethod()
            {
                throw new Exception();
            }
        }

        private class NonFakedClass
        {
            private readonly FakedClass _fakedClass = new FakedClass();

            public Task NonFakedMethodAsync()
            {
                return Task.Factory.StartNew(() => _fakedClass.FakedMethod());
            }

            public void NonFakedMethod()
            {
                _fakedClass.FakedMethod();
            }
        }

        [Fact]
        public async Task TestMethodAsync()
        {
            Isolate.Fake.AllInstances<FakedClass>();
            NonFakedClass nonFaked = new NonFakedClass();

            // FAILS
            await nonFaked.NonFakedMethodAsync();
        }

        [Fact]
        public void TestMethod()
        {
            Isolate.Fake.AllInstances<FakedClass>();
            NonFakedClass nonFaked = new NonFakedClass();

            // SUCCEEDS
            nonFaked.NonFakedMethod();
        }
}


Is there a way to fix this, or is this a bug / limitation of Typemock?
asked by Jahmai (2.8k points)

2 Answers

0 votes
Hi,

We've designed Isolator to work best with unit tests, which in our case means testing logic on a single thread. In that sense, it's limited in support for multi-threaded code, but for the right reason.

What I suggest is that you try to test the code that runs on the separate thread and not the combination of multiple threads. It's not going to be a bad test - just not a unit test.

I'll be happy to help with writing these tests, so if you get stuck let me know.
answered by alex (17k points)
0 votes
Hi,

We've designed Isolator to work best with unit tests, which in our case means testing logic on a single thread. In that sense, it's limited in support for multi-threaded code, but for the right reason.

What I suggest is that you try to test the code that runs on the separate thread and not the combination of multiple threads. It's not going to be a bad test - just not a unit test.

I'll be happy to help with writing these tests, so if you get stuck let me know.


C# now has extensive support for asynchronous code using the async/await keywords and by following the Task-based Asynchronous Pattern.
Such methods often run on worker threads in the thread pool, and therefore by their very nature are not single threaded.

These methods are still part of a unit of work that is testable like any other method. In fact, Typemock works just fine when you use the Wait() and Result members of Task's returned from such methods. So to this end, Typemock works perfectly well testing code that executes on other threads.

Also, Typemock handles the async/await keywords perfectly well when the code does not require isolation - for example, when you do not use Isolate.Fake.AllInstances().

As far as I can tell, the only problem here is Typemock does not correctly respect the [Isolate] attribute for the auto generated private classes that these methods create behind the scenes.

Given that TAP/TPL code is becoming more common in C# libraries, I encourage Typemock to improve support for this.
answered by Jahmai (2.8k points)
...