Matthew’s response is probably all you want in principle,
but I think that your ‘unit test’ looks like another person’s
‘integration tests’. Both are useful.

Wouldn’t you want to use unit tests to validate the parser
independently of the macros that expand the S-expression
syntax you create with the parser? If you then discover a
failure, it becomes much easier to search for the bug in
either of the two pieces. (I understand that there are many
more pieces but let’s say ‘two’ for now.)

Thanks for your reply!

I guess what I want to do is somewhere in between unit and integration tests. I don't really care much about the labels.

I do have unit tests for the low-level implementation details of my #lang. They are plain Racket functions with straightforward tests.

What I want to write additional tests for is

 1) The macros that expand the S-expression for my module

 2) Some of the functions used in the expansion, for which
    suitable input is difficult to generate without those

The parser is not my problem - it's borrowed from Scribble and presumable tested by someone else :-)


You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to