Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #52.
This is a first pass for this feature so design input is requested.
Initial decisions:
use-fixtures
fromclojure.test
for fixture functions thatapply to all of the tests in a namespace. Note that this does not
support
:once
fixtures as of yet because the runner does not run alltests in a namespace as a group that can be
:once
d. This willrequire a change to
greenlight.runner
.::test/each
as an option to thedeftest
attribute map. Thisneeds to be a collection of fixture functions. This could not quite be
expressed via the
use-fixtures
method because it would unilaterallyapply a fixture function to all steps in all tests in a namespace.
This could be an additional feature as well.
Open questions:
namespace that allows for composable definitions of fixtures in the
way that steps are composable? Something like
deffixture
, agreenlight-specific
use-fixture
for top-level, and then fixtureconfiguration at the test/step level.
modifiable by the fixture functions? e.g., should downstream steps see
the changed context and should the test output contain that changed
context. This gets a bit sticky and pushes on the
deffixture
idea,in that greenlight tries to be explicit about its data dependencies
and outputs, but with fixtures that can take/update context, declaring
data dependencies gets a bit hairier. I can imagine that
deffixture
would also declare inputs and outputs, which could then get merged
into the step inputs/outputs. Depends on how complex this needs to be.