G'day:
This immediately follows on from "CFML: Adding beforeEach handlers to my TinyTestFramework. Another exercise in TDD".
Having done the beforeEach implementation for my TinyTestFramework, I reckoned afterEach would be super easy: barely an inconvenience. And indeed it was. Took me about 15min, given most of the logic is the same as for beforeEach.
Here are the tests:
describe("Tests of afterEach", () => {
it("will not break if an afterEach is not specified for a given describe block", () => {
expect(true).toBeTrue()
})
describe("Baseline", () => {
result = []
afterEach(() => {
result.append("set in afterEach")
})
it("runs after a test (setup)", () => {
expect(result).toBe([])
})
it("runs after a test (test)", () => {
expect(result).toBe(["set in afterEach"])
})
})
describe("Works in a hierarchy (top)", () => {
result = []
afterEach(() => {
result.append("set in afterEach in outer describe")
})
describe("Works in a hierarchy (middle)", () => {
afterEach(() => {
result.append("set in afterEach in middle describe")
})
describe("Works in a hierarchy (inner)", () => {
afterEach(() => {
result.append("set in afterEach in inner describe")
})
it("runs all afterEach handlers, from innermost to outermost (setup)", () => {
expect(result).toBe([])
})
it("runs all afterEach handlers, from innermost to outermost (test)", () => {
expect(result).toBe([
"set in afterEach in inner describe",
"set in afterEach in middle describe",
"set in afterEach in outer describe"
])
})
})
})
})
describe("Tests with beforeEach as well", () => {
result = []
afterEach(() => {
result.append("set by afterEach")
})
beforeEach(() => {
result.append("set by beforeEach")
})
it("is the setup test", () => {
expect(true).toBeTrue()
})
it("tests that both beforeEach and afterEach got run", () => {
result.append("testing that the preceding setup test had its afterEach called")
expect(result).toBe([
"set by beforeEach", // setup test
"set by afterEach", // setup test
"set by beforeEach", // this test
"testing that the preceding setup test had its afterEach called"
])
})
})
})
These are more superficial than the beforeEach ones because most of it is already tested in those tests. I just test that it's called, works in a hierarchy (no reason why it won't given the implemntation requirements, but it's a belt-n-braces sort of test), and works with a beforeEach in play before. One thing to note is that I need to run a stub/control/setup test before my test of afterEach, because obviously it runs after the test's code, so we can't test what it does with a single test. Hopefully you see what I mean there. That's the chief difference.
The implementation is simple:
beforeEach = (callback) => {
tinyTest.contexts.last().beforeEachHandler = callback
},
afterEach = (callback) => {
tinyTest.contexts.last().afterEachHandler = callback
},
it = (string label, function implementation) => {
tinyTest.inDiv(() => {
try {
writeOutput("It #label#: ")
tinyTest.contexts.each((context) => {
context.keyExists("beforeEachHandler") ? context.beforeEachHandler() : false
})
implementation()
tinyTest.contexts.reduce((reversedContexts, context) => reversedContexts.prepend(context), []).each((context) => {
context.keyExists("afterEachHandler") ? context.afterEachHandler() : false
})
tinyTest.handlePass()
} catch (TinyTest e) {
tinyTest.handleFail()
} catch (any e) {
tinyTest.handleError(e)
}
})
},
// ...
afterEach = tinyTest.afterEach
That is literally it.
The only non-obvious thing is this:
tinyTest.contexts.reduce((reversedContexts, context) => reversedContexts.prepend(context), []).each((context) => {
context.keyExists("afterEachHandler") ? context.afterEachHandler() : false
})
Where the beforeEach handlers are run from the outermost to the innermost context, the afterEach ones are run in the reverse order.
That's it. I'll add these to the source code:
- Gist with combined framework and tests.
- Just the framwork.
- Just the tests.
- trycf.com runner with TinyTestFramework loaded.
Righto.
--
Adam