Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simpler implementation of test suites #74

Open
jackfirth opened this issue Aug 29, 2017 · 0 comments
Open

Simpler implementation of test suites #74

jackfirth opened this issue Aug 29, 2017 · 0 comments
Labels

Comments

@jackfirth
Copy link
Sponsor Collaborator

Currently, the internal representation of test suites has a notion of a "seed", which is threaded throughout the test by means of a complex and indirect chaining of lambdas and parameters. This seed itself has no effect at all on the evaluation of a suite; instead it is used by fold-test-suite and foldts-test-suite to thread a "current state" value through the evaluation of each test.

A simpler implementation would have a test suite encapsulate a thunk returning a stream of values: the results of evaluating each expression immediately within the suite. The fold-test-suite function could inspect this stream for nested suites, keeping track of the "seed" value on its own. This would make the implementation of test suites much more understandable without breaking the API.

Of special note is this section in the docs of foldts-test-suite:

If you’re used to folds you’ll probably be a bit surprised that the functions you pass to foldts-test-suite receive both the structure they operate on, and the contents of that structure. This is indeed unusual. It is done to allow subtypes of test-case and test-suite to be run in customised ways. For example, you might define subtypes of test case that are ignored (not run), or have their execution time recorded, and so on. To do so the functions that run the test cases need to know what type the test case has, and hence is is necessary to provide this information.

It is not possible to define subtypes of test cases or suites with RackUnit's public API (you have to (require rackunit/private/base) to do that) and doing so is probably a bad idea. This function should be deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant