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
Welcome to Typemock Community! Here you can ask and receive answers from other community members. If you liked or disliked an answer or thread: react with an up- or downvote.
0 votes
My test method Test should throw exception, so, I used ExpectedException attribute, I also expect 2 calls to the Foo.Bar1 function and use VerifyMocksAttribute to verify mocks. But, when exception thrown VerifyMocksAttribute does not work. It not calls MockManager.Verify()!. Is it bug or feature?

namespace ClassLibrary4
{
    public class Foo
    {
        public static void Bar1()
        {
            throw new IndexOutOfRangeException();
        }

        public static void Bar2()
        {
            throw new IndexOutOfRangeException();
        }
    }


    [TestClass]
    public class Class1
    {
        [TestInitialize]
        public void TestInitialize()
        {
            MockManager.Init();
        }

        [TestCleanup]
        public void TestCleanup()
        {
            MockManager.ClearAll();
        }

        [TestMethod]
        [VerifyMocks]
        [ExpectedException(typeof(IndexOutOfRangeException))]
        public void Test()
        {
            using (RecordExpectations recorder = new RecordExpectations())
            {
                // waiting 2 calls to the Bar1 function
                Foo.Bar1();
                Foo.Bar1();
            }
            
            Foo.Bar1();
            Foo.Bar2();

            // only one call to the Bar1 made, so, .Verify should fail the test
        }
    }
}
asked by tom3m (9.7k points)

8 Answers

0 votes
Hi,

When we implemented the verifyMocks attribute we tried to make it behaves exactly the same as if a MockManager.verify() statement is added at the end of the test.

So the behavior that you describe is by design.
If you throw an exception inside the test code verification is not done. (since the "end of the method" is not reached).

you can however put a try catch block inside the test instead of using the ExpectedExceptionAttribute,
OR
It shouldn't be too hard to implement a new ExpectExceptionAndVerify attribute using our custom attribute mechanism.
(are you feeling up to it ?:twisted: )
answered by lior (13.2k points)
0 votes
Ok, I see. but, calling Verify from finally/catch block loking not so perfect as attribute.

What can i suggest - is implement one more constructor in the VerifyMocksAttribute where I can specify behaviour. E.g. VerifyMocksAttribute(bool verifyOnException) or VerifyMocksAttribute(bool alwaysVerify).

PS:
I'll try implement my own attribute.
answered by tom3m (9.7k points)
0 votes
I agree, a try catch block is not as "clean".

After your post we discussed it little and came up with 3 possible solutions:
1) as you suggest adding another ctor to define such a behavior.
2) doing a new attribute.
3) automatically detecting if an exception is expected and in those cases perform a verify also.

what do you think?

PS
A good place to start would be with our TraceableAttribute which can be found in the examples project.
In any case et me know how it goes or if you need any help. I would more then appreciate any feedback on our attribute mechanism.
answered by lior (13.2k points)
0 votes
I hate 3nd solution, I'm sure you should not do magic, like detecting something (take into account there is different unit testing frameworks with different attributes, so, you'll need detect NUnit/MSTest and other attributes, I dont think its good idea).

2nd solution, I dont see the reason why we need introduce new attribute, and how you going name it?

So, I'm voting for 1st solution.
answered by tom3m (9.7k points)
0 votes
Yestarday I was thinking about that issue, I feel if we're going add new constructor - it should accept exception type, to call .Validate only when expected exception thrown. If another exception thrown TypeMock should not call .Validate and its very important!

How do you think?
answered by tom3m (9.7k points)
0 votes
Hi,

I would agree. passing the exception type would be necessary.
and yes if the exception is different Verify should not be called (if it is called the user would most likely see a verify exception and not the original exception that was thrown)
answered by lior (13.2k points)
0 votes
:arrow: I wouldn't like to rewrite the ExceptionType
[ExpectException(typeof(ExceptionType))]
[VerifyMocks(typeof(ExceptionType))]


What do you think of this API.
[ExpectException(typeof(ExceptionType))]
[VerifyMocks]

:idea: TypeMock will verify mocks if all Asserts pass and ExceptionType is thrown
answered by scott (32k points)
0 votes
2scott:

The question is how to implement it. Currently, as I understand, TypeMock.NET is independent from different unit testing frameworks. So, if you going 'detect' exception type from ExpectException attribute you'll add dependency from Microsoft Unit Testing framework. Am i right? If so, you'll need then implement the same behaviour for other different unit testing frameworks, as NUnits and so on. So, I dont think its good idea. 1st variant is better IMHO.
answered by tom3m (9.7k points)
...