Scott Bellware has some post on Behavior-Driven Development (BDD) syntax for NUnit, and a post comparing the syntax to RFC 2119.
Having implemented a few RFC’s that use RFC 2119 syntax, I found this comparison very on the button. As I developed routing protocol’s the Must‘s and _Should’_s related to how you must respond or act when things happen. Very much state machine type stuff. When things said must, well that’s what you did. The should‘s were always related to internal state machine processes. A lot of them where your peer may tell you this, or may not (thus a should) but, you have to deal with both possibilities.
The flip side for BDD where should is used instead of an Assert makes a lot of sense. My code was always littered with Asserts of the should nature. When you are writing the code, there are question in my head, so it’s simple to test and find out if I’m wrong. I’d also use Assert‘s to Assumed‘s. Then I’ll know it all good.
The problem with Asserts in a production system where any Assert failing takes the whole system down (as it did for ours), meant that any failing Asserts in the wild made the whole product look “bad” so Assert’s ended up large if statements, with recovery code embedded there. This was an embedded C system, so no fancy try/catch block for us.
But all the history aside, for testing purposes, should feels like a better world than Assert. It also removes the false is logic, were false is bad while true is good.
Gosh, damn, I have to say Extension Methods so look hot chocolate good. I’m sure they have some down side, maybe just like hot chocolate, too many and you feel sick?