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
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));
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.