Journal of my investigation into the development of a new programming language
Testability of Procedures
I'm using the Pascal distinction of functions (which return a value) and procedures (which don't) here. Procedures in the C family are just functions with the void return type.
For zero button testing, I've come up with syntax that I'm very happy with: expect...returns. This allows tests to be written right in the function body. For instance:
. . expect 1 returns 2
. . return 2 * x
For test-driven development, this seems like a great way to go - you write the function name, then immediately the test(s). With zero button testing, the test name starts out yellow (it has no tests) then turns red as soon as the first test is written (and fails, because the function doesn't return anything
yet). Then you write the function body, correctly, and it all turns its natural shade of white or perhaps gray. As you type.
A little extension to this to answer the immediate question of how to test member functions - in addition to expect
, let's add archetype
to our list of keywords. With that, now we have:
. . archetype none(0, 0)
. . archetype some(1, 2)
. . contains x:
. . . . expect none 1 returns false
. . . . expect some 1 returns true
. . . . x < low? return false
. . . . x >= high? return false
. . . . return true
That is to say, we expect that when the empty range none is asked whether it contains 1, it should (and does) return false; when some is asked, it returns true. Some contains 1 and none doesn't.
That's all well and good - but when it comes to procedures, which don't return anything at all, I don't know how to express the tests so nicely. Invoking the routine and testing its effects are separate steps. So - a puzzle.
works well for functions, but not procedures.