On Mar 4, 2011, at 5:11 AM, Neil Van Dyke wrote:
> Could someone explain the advantages of having, say, the "test-suite" form
> produce a data structure to be supplied to test-runner code... rather than
> having evaluation of the "test-suite" form result in the tests actually being
> executed?
In my latest project, I have arranged things like this:
module_i.rkt : includes all code for some data representation and its
functionality,
plus test suites, usually several of them one per functionality
or one per important interaction between two pieces of functionality
I use define/provide-test-suite to formulate the test suites
*after* I have developed the code. During the initial code
development, I stick to plain check-* test cases.
Tests/module_i.rkt : once I have a stable module, I move the run-tests
expressions to a separate module in a test directory. Not the
test suites, which stay with module, just the run test suites
thingies, e.g.,
#lang racket
(require racket/require (path-up "board3.rkt") rackunit
rackunit/text-ui rackunit/gui)
(define board-test
(make-test-suite "testing the board"
(list --side
--board-draw
--board-ref
--board-set
--board-init
--board-place-piece?
--board-score
--board-put
--board-connectable
--serialize)))
(run-tests board-test)
When I have to do anything on module_i.rkt, I open both the module and its
pendant in Tests. A change in the former means I run the latter.
What do I get from this:
1. I like to formulate tests in the context of the function definition.
I prefer reading things that way.
2. I do not run the tests when I load the module. I run them only when I test.
3. I don't have to export all the 'private' functions from the module.
(I know I can get there anyway, but I find this bad.)
-- Matthias
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
