Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

My blog has moved. You can view this post at the following address: http://www.osherove.com/blog/2009/7/9/minimizing-unit-test-fragility-8-features-in-typemock-isolat.html
Published Thursday, July 09, 2009 6:52 PM by RoyOsherove
Filed under: ,

Comments

Thursday, July 09, 2009 8:15 PM by Brian Mains

# re: Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

Roy,

Good article.  I haven't had the same success with Isolate.WhenCalled() though... when I do:

Isolate.WhenCalled(() => o.CallMethod(null))...

And the method does:

CallMethod(string name)

{

  if (string.isNullOrEmpty(name))

     throw new Exception("name is null");

  .

  .

}

It throws an exception for me in the WhenCalled statement because the null value caused issues.

Will using a constant/object circumvent that issue?

Thanks.

Friday, July 10, 2009 12:21 AM by RoyOsherove

# re: Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

Brian, yes, that would solve it.

since we are invoking the method as part of our internal process, we can only send in values that are legal for the code in themethod (we have no way of knowing if null is valid or not)

Friday, July 10, 2009 3:32 AM by Doron

# re: Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

Brian, can you post the complete test and exception message, or drop an email with the details to support at typemock.com? It seems like your code should work - the null value should not cause an issue.

Friday, July 10, 2009 4:37 AM by Eli Lopian

# re: Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

@Brian, WhenCalled() doesn't actually run the methods logic and so it shouldn't throw any exception. If you define a .CallOriginal() behavior then you will get an exception when the method is called.

@Roy,

You can add the Array/IEnumerator behavior - allowing developers to switch between either in the production code without needing to change  the test.

So a: WhenCalled(()=>fake[5].Name).WillReturn("Roy");

will work regardless of the access method used in the production code (all these will pass)

for (int i = 0 ; i < real.Count; i++)

  if (real[i].Name == "Roy")

     count++;

foreach (var item in real)

  if (item.Name == "Roy")

     count++;

count = real.When(i=>i.Name=="Roy).Count();

Friday, July 10, 2009 7:27 AM by DotNetShoutout

# Minimizing unit Test Fragility – 8 features in Typemock Isolator to help - Roy Osherove

Thank you for submitting this cool story - Trackback from DotNetShoutout

Friday, July 10, 2009 4:00 PM by Brian Mains

# re: Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

Hello,

Doron, Eli, I will double-check this and get back to you.  Last I remember, if I did:

Isolate.WhenCalled(() => o.Call(null, null)).WillReturn(1);

I got an exception thrown.  Will double-check and post something on the forum.  Consequently, I thought I already did, but I can't find it, so I'll post again.

Thanks.

Monday, July 13, 2009 4:15 AM by Sanjeev Agarwal

# Daily tech links for .net and related technologies - July 9-13, 2009

Daily tech links for .net and related technologies - July 9-13, 2009 Web Development Using Custom T4

Monday, July 13, 2009 10:29 PM by Brian Johnston

# re: Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

Not lazy web...just over-worked folks who have no time to surf lately!

Thursday, July 16, 2009 6:14 PM by Brian

# re: Minimizing unit Test Fragility – 8 features in Typemock Isolator to help

Hmm, I'm not getting the same result.  Isolate.WhenCalled() is working.  Don't know what it was related to originally (maybe some other error), but if I get it again, will let you know.  Thanks all for the guidance.

Saturday, July 18, 2009 9:15 PM by #.think.in

# #.think.in infoDose #37 (12th July - 19th July)

#.think.in infoDose #37 (12th July - 19th July)