@lexi.lambda: Have you worked on your BDD framework idea much? I’m really curious to see it

notjack: I’ve implemented describe and it, which were pretty easy, but I need to implement the output printer

@lexi.lambda: How’s writing tests in it look? I’m wondering if maybe integrating it with scribble and the @ reader would let you generate a manual-style document from the tests like scribble/lp

notjack: I’m usually skeptical of generating docs from tests, but maybe generating examples? I’m not sure, though.

It might also be a separate thing that could be built on top of a BDD framework instead as well.

Does it work with rackunit at all? Like the describe/it/should wraps individual rackunit checks? Or does it implement it’s own testing system?

wondering if I can hook up an integration testing thing I’ve been making to it

@lexi.lambda: Have you got it on github?

notjack: describe and it are just sugar for test-suite and test-case, except that the outermost describe block automatically runs the tests

but no, it’s not on github yet

@lexi.lambda: That’s great

toss it up when you get a chance

will do… I’m still not sure if my current solution to auto-running top-level describes will make sense, mostly because that will print two separate sets of output

How so?

which doesn’t work nicely at all for interspersed (module+ test …) forms

well, somehow I need to collect all the test-suites

and I don’t want rackunit’s default output

I’d like to display a prettier system using the descriptions provided via describe, it, and context

but that means I need to somehow get at all the results of the describe blocks

like jasmine-node outputs for example?

yeah

and I can’t really do that all that easily without replacing #%module-begin or something like that

I don’t recall how much support rackunit has for custom output formats and the like

it sorta kinda does, but no way to do it globally like I want to do (which makes sense)

I haven’t come to any conclusion about how to do it properly

test-suites plus taking control of output ports maybe?

well, test-suites don’t autorun

which is sort of the point

I need all the data from all the test suites before I start printing anything

Hmm. What about if describe and friends made test suites, but also added a main submodule to the module they’re in that ran them?

That way you would autorun them when running that file in drracket, but they’d be available for other modules to require and run tests from multiple modules at once

There’s some macro to do that I recall, lift-module-end-definition or something like that, that lets you add arbitrary code to the end of whatever the current module is

but that still doesn’t tackle the whole “collect all the defined test suites” problem for a single module, as the main module would need a list of all test suites in the module to run rather than each describe creating a single run command

that’s tricky

It’s definitely something I need to look into more once the basics are done

@lexi.lambda: I got a hacky thing working where describe defines a test suite in a submodule, and a run-bdd-tests (or what have you) macro creates a main submodule that dynamic-requires everything in the test suites submodule to get a list of test suites.

It feels rather gross though

Hmm, can you have main submodules inside of test submodules?

.oO(That seems like a strange idea. Hmm.)

Don’t know. Testing to see if that actually gets run

Nope, drracket’s run button doesn’t run a main submodule inside a test submodule

It seems like it would be a nice generalization to say “whenever a module gets instantiated, if the file it’s in is the main file being run, instantiate the main submodule inside it”

not a lot of uses for it though

You could probably make it work with clever uses of submodules, but it’d be pretty hacky

I wonder who maintains rackunit

Looks like @rmculpepper

What exactly should the output look like when testing multiple files?

I haven’t even really considered how to aggregate multiple files yet, especially since raco test has no concept of multi file suites

Maybe just not even bother with that and let raco test commands break up output? Something like $ raco test mod1.rkt foo - when given a widget -- should frobnicate it (checkmark) - when given a gizmo -- should treat it like a widget (x mark) bar ... $ raco test mod2.rkt baz ... maybe?

Yeah, I haven’t really worried about it yet

Eventually it might be nice, but that’s not necessary for now

Yeah

Perhaps it would make more sense to provide simpler output when running with raco test and then provide the more complex output with a raco spec command that only works on files using rackunit/spec

It could use the approach from scribble/srcdoc and generate submodules that can then be required to get at the information

That would make sense. Then if you wanted more control over customizing the output at the command line you could add your own switches easily

And some other yokel (cough: me) could add a raco literate-spec command that generates a scribble doc from the tests