<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 11, 2014 at 9:14 AM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That, sadly, doesn't work, because here a is a message send to So.<br>
What you need is a message taking a (and b) as parameters, which<br>
requires two words before the word "a". I'm kind've leaning towards<br>
Assert: Assert that: a equals: b.<br>
<br>
In RSpec, changing the assertion language means not having to monkey<br>
patch. In our case, TestCase does a whole pile of stuff. One of those<br>
things is a DSL (domain specific vocab, as Colin put it - maybe even<br>
"domain specific jargon") in the form of #assert: and friends. Pulling<br>
that out into (say) Assert means factoring things better. JUnit also<br>
did this, AFAIK, when they pulled in the Hamcrest matchers. (Assert<br>
isn't a novel idea, btw: I've stolen it from NUnit:<br>
Assert.IsTrue(proposition), Assert.AreEqual(a, b).)<br></blockquote><div><br></div><div>It's true; it would separate the machinery for running tests (TestCase and friends) from the vocabulary for expressing expectations . Node.js does this nicely, and there's a selection of both test runners and assertion libraries that you can mix and match. </div>
<div><br></div><div>However, using a global like that makes customizing the vocabulary awkward. You'd have to add class-side extension methods to Assert, possibly leading to extension conflicts between different test packages. </div>
<div><br></div><div>One idea is to wrap the value being verified in an assertion proxy. It would forward messages to the object being examined, and intercept the answer. If the answer is false, it raises a TestFailure, other wise it wraps the answer and returns it. That would enable things like:</div>
<div><br></div><div>it := Assertion for: [3 + 4].</div><div>it > 6.</div><div>it = 7.</div><div>it < 8.</div><div>it + 1 = 8.</div><div>it negated = -7.</div><div><br></div><div>Then you could make a custom wrapper if you wanted more abstract assertions:</div>
<div><br></div><div>it := EnvironmentAssertion for: </div><div> [(Environment named: #test)</div><div> exportSelf;</div><div> bind: #Griffle to: Object new;</div><div> yourself].</div><div><br></div><div>
it exports: #Griffle.</div><div><br></div><div>That's kind of neat, but I suspect it breaks down when you have non-trivial tests. It's tough to beat the simple #assert:.</div><div><br></div><div>Colin</div></div></div>
</div>