After seeing Pex in action at PDC 2008 I have caught the fever.

Since then, I gave it a whirle on my own and was pretty impressed. So much so, I chose it as a topic for one of my So-Cal Code Camp  talks in January. Got some very good questions and concerns regarding the capabilities and place of Pex in the world of software development and vis-a-vis TDD.

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.