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

Try the following production code

    public abstract class BaseClass
    {

        public int Version
        {
            get
            {

                return 1;
            }

        }

        public string FixString
        {
            get;
            set;
        }

        public BaseClass()
        {
            FixString = "hello";
        }
    }


    public class DeriveClass: BaseClass
    {


        public DeriveClass():base()
        {

        }
    }


And the following test code

   [TestFixture]
    public class BaseClassTest<T>
        where T:BaseClass
    {

        public T BaseClassObj
        {
            get;set;
        }
    }
    [TestFixture, Isolated]
    public class DeriveClassTest:BaseClassTest<DeriveClass>
    {
        [Test]
        public void Test1()
        {
            BaseClassObj = new DeriveClass();
            Isolate.WhenCalled(() => BaseClassObj.Version)
                .WillReturn(5);
            Assert.AreEqual("hello", BaseClassObj.FixString);
        }
    }



The test fails, even though it should pass.

It seems that derived test class with generics will cause problem.
 

asked by nsoonhui (59.1k points)
edited by Bar

4 Answers

0 votes
This is a test pattern that I particularly like when developing plugins, is it possible to fix this soonest and send me a patch?
answered by nsoonhui (59.1k points)
edited by Bar
0 votes
Thank you very much for the repro. I will open a support ticket and will update you as soon as possible.
answered by igal (5.7k points)
0 votes
We've been able to identify the bug: because 'BaseClassObj' is a property, we fake it and replace it with recursive fake. That's why the 'Version' value is set correctly - there's an explicit expectation on it...

This is now an open issue in our bug system. While it's not ideal, as a workaround, you could make the BaseClassObj a public field instead.
answered by igal (5.7k points)
0 votes
Thanks for the workaround...
answered by nsoonhui (59.1k points)
edited by Bar
...