Assertions for Synergy/DE

Perhaps you’ve heard of Test-Driven Development (TDD)?  Like many good development strategies that have evolved over the years, I have been practicing an informal version of this for about a decade — on my good days.  The idea is that you construct tests for new features before you write them (or at least, while you write them), and that you run all prior tests along with the new ones as you implement the features.   This helps ensure that you cover all aspects of the new requirements and that you don’t introduce any unintended consequences.

Because you’re writing so many tests, a framework for developing those tests can save you a lot of time.  A good example of a test framework is Ruby’s Test::Unit module, a key feature of which is Test::Unit::Assertions.  Assertions provide a short-hand way of performing an “expected vs. actual” test and throwing a special class of exception when the test fails.  The unit test harness can then catch that class of exception and report failures in a consistent and centralized manner.

The downloadable code below contains an implementation of assertions for Synergy/DE version 9 and greater.  Simply include “assertions” in your test routine, then use one of the assert macros to test for an expected case.  These are implemented as macros rather than functions in order to postpone type evaluation of arguments until after the code is generated.  See the included assertions.txt for full documentation, but here’s a brief example:

record
        lval ,int
proc
        lval = myfunc()
        assert_equal(1, lval, "Return value for myfunc was %d, expected %d")

Note that I could have embedded myfunc() as the second argument to assert_equal(), but then it could be executed twice: once when evaluating the assertion, and again when formatting the message.  Besides, you can conditionally turn off assertions (in case you want to embed them in production code) — so you really want the arguments to an assertion to be free of side-effects.

I intend to expand on this to create more tools for testing, like test runners, cases and suites — but this can act as a first taste test.

It would also be useful to develop something like Assaf’s assert_select for user interfaces, but that will take quite a bit of thought for Synergy/DE.