(+N) Consulting Inc.

Consulting. Software solutions. Training.

Unit Testing and approval tests

It's been years now that unit testing frameworks and tools have grabbed our attention, made their way into our favorite IDE and sparked yet another wave of seemingly endless "my framework is better than yours" wars. And then there are the principal wars of whether TDD is better than Test After Development. And most excitingly the automated testing tools etc. Oh, and let's not forget mocks! So we have all the tools we need – right? Well, kind of, no. [More]

Waiting for Pex to release

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.  

Pex Gotcha - watch your predicate expressions

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.

Unit testing value tests - Automate repeated tests

It is generally considered a good thing to use unit tests these days. Often it is necessary to test a method which takes some complex type. So in the unit testing one has to painstakingly manufacture such object, and pass it in.
Before doing so, you would (should!) ensure the complex type itself produces an identity - that is to say that if you create an instance of type MyClass and assign / construct it with proper values your should "get back" what you gave it. This is especially true for object that get serialized and de-serialized. [More]