Categories: General Posted by nurih on 1/16/2009 10:25 PM | Comments (0)

It's that time of year again - Code Camp is next week, hosted at Cal State Fullerton.

Many good presenters, many good sessions.

Show up for one day both two, it's free to attend!

Check it out, come by
Tags: , , , | Categories: Code Development, Testing, Web Posted by nurih on 1/16/2009 10:25 AM | Comments (0)

Just came back from another great SoCal Code Camp. I had some valuable insights and discussions about TDD and the use of Pex. Thank you attendees!

While developing the presentation for Pex, I ran into a situation where the Pex.Assume() did not seem to work at all:

Consider the function

public List<short> MakeList(short baseNum, short count) 
{ 
List<short> result = new List<short>(count); 
for (short i = 1; i <= count; i++) 
{ 
result.Add((short)(baseNum * i)); 
} 
return result; 
}

 

Pex correctly identifies a potential flaw where the multiplication (baseNum * i) would result in overflow.

Adding a filter

PexAssume.IsTrue(baseNum * count < short.MaxValue); 

 

Seems like it would do the trick – but it doesn't.

Several rebuilds, clean solution, shake heads and searches for bugs later I found the issue: The predicate provided to PexAssume.IsTrue(predicate) produced an overflow! So when pex explores it would have tripped the condition I was trying to avoid by evaluating the parameters I tried to filter out.

The fix was to rewrite the filter as:

 

PexAssume.IsTrue(short.MaxValue / count > baseNum); 

 

Here, the math would not produce an overflow. Combined with PexAssume(count>0) and PexAssume(baseNum>0) my now filters work as (I) expected.

 

The take home is pretty obvious – ensure the predicate does not throw – but identifying it took a bit of head scratching.