OLD Contexts as an abstraction over Class based and Test based setup and teardown

Overview

Originally created by @schauder.

In JUnit 4 and prior versions there seems to be an abstraction missing. When looking at the NestedTestContexts example, that TestContext might be the thing I'm looking for.

Background

In JUnit 4 we have

• Before/After & Rules which work on a individual test level

• BeforeClass/AfterClass & Rules which work on a test-class level

• We have nothing of this kind which work on a package level, or some other grouping of tests

• We have nothing of this kind for all tests.

• We have the requirement to control the execution order of tests which makes sense only for groups of test, but can't work on arbitrary groups of test, because the may overlap.

I was missing the later two multiple times. For example consider integration tests which all needed a certain setup based on a Spring context. Or limiting all tests to an execution time of n seconds.

TestContext

There is one RootContext that does not have a parent. Every other TestContext has exactly one parent. Each test is a TestContext.

Test modifiers (like Rules from JUnit 4), setup/teardown can be registered on TestContexts.

Those test modifiers can among other things change the ordering of contained TestContexts.

TestModifiers can get applied on a TestContext on all levels.

JUnit 4 style tests can create a TestContext for the TestClass and apply Rules/Before/After accordingly.

Probably it makes sense to build the TestContext hierarchy based on the package hierachy for Java code based tests, but JBehave kind of tests might differ.

TestModifier

TestModifier needs the following:

• Behavior (obviously)

• A TestContext to which they are applied. TestModifiers have no effect whatsoever on tests that are not contained (directly or indirectly) in that TestContext.

• The level on which they are triggered. So you might have a TestModifier on the de.schauderhaft package that gets invoked for each test (leaf nodes) of the TestContext hierarchy. I'm not sure if it makes sense to allow other levels than the TestContext the TestModifier was registered for and each test contained needs.