Comments on: Testing assumptions with preconditions

By: bogardj

bogardj — Thu, 27 May 2010 12:15:37 +0000

@Martin

Yep, it’s an assumption, but also the simplest thing that could possibly work. I still don’t introduce duplication, that would be bad. But I don’t really see the point of allowing this value to be configurable, when no one needs it to be. Unless it’s for non-functional requirements, I’m just not a fan of “just-in-case” development.

By: Michael Chandler

Michael Chandler — Thu, 27 May 2010 12:07:40 +0000

@bogardj Code contracts allow for preconditions, postconditions and invariants. You /could/ use an invariant but they’re checked at the /end/ of all public method calls, not the start. Besides, the constant isn’t really a contract.

I really like the idea of having the tests fail when the constant value is changed. It really makes you think and recognise what the implications for of making the change are.

By: Martin Evans

Martin Evans — Thu, 27 May 2010 10:49:08 +0000

I suspect the biggest assumption you’ve made is believing the customers original statement that the reward limit value has never changed and never needs to change!!

Perhaps my experience hasn’t shaped my opinion enough to follow the JFHCI mantra at the moment but I’d be a little nervous about setting that value to a constant.

By: bogardj

bogardj — Thu, 27 May 2010 00:01:39 +0000

@Ryan

I thought code contracts were only for method parameters? Here, it’s just a hard-coded const, how would I use code contracts?

@Harry

That’s pretty cool, I didn’t know about that piece! Thanks for the heads up!

By: Harry Steinhilber

Harry Steinhilber — Wed, 26 May 2010 22:09:54 +0000

I like to do the same thing for my tests, only using NUnit’s Assume.That() instead of a Debug.Assert(). It allows all the tests to fail with an inconclusive result to show my assumptions are wrong, not the test.

By: Ryan Riley

Ryan Riley — Wed, 26 May 2010 20:12:52 +0000

Have you considered Code Contracts? We’re not using them (yet), but I’ve also gotten pushback on using debug.assert instead of hard exceptions.

By: bogardj

bogardj — Wed, 26 May 2010 18:06:24 +0000

@Darrell

Quite a few times I’ll have calculations based on these constants, so I personally prefer not to duplicate the calculation logic to arrive at the expected result in my unit test. Otherwise, no real harm, and probably just a preference thing.

@John

I go back and forth on this one, trying to figure out what best conveys the intent of the design.

By: chadmyers

chadmyers — Wed, 26 May 2010 14:43:56 +0000

I call these “booby traps” If you change some fundamental assumption of the system, it should trigger a tripwire and smack you in the fact so you have to think about the consequences.

I like all my surprises up front and during development when I can deal with them properly vs. being surprised during a customer demo or live in production

By: John Bennett

John Bennett — Wed, 26 May 2010 14:25:48 +0000

I like the JFHCI approach for this type of thing. However, if the value is public I use “static readonly” instead of “const”. That at least gives me the freedom to change the value in the future without having to recompile all the consuming assemblies that might have used it.

By: Darrell Mozingo

Darrell Mozingo — Wed, 26 May 2010 14:17:20 +0000

What would the downsides be to just using the constant in your tests, along the lines of result.ShouldEqual(Customer.GedgetSpendRewardLimit) rather than result.ShouldEqual(200m)? Then changing the constant’s value wouldn’t affect the tests.