Mocha has several 'hooks' to run assistive functionality in a test separate from the test cases themselves (clearing databases, creating mock files, etc).
However, in the case of before()
(not beforeEach()
, that one I get), it seems pretty redundant.
before()
runs the logic once before all of the tests in the current suite, so why do I need to even wrap it in a function?
There's no observable difference between the two following:
describe('Something', function() {
before(doSomePreTestLogic);
//Tests ahoy
});
and
describe('Something', function() {
doSomePreTestLogic();
//Tests ahoy
});
What's the point of wrapping my pre-test logic with before()
?
The Upshot
Put directly inside a
describe
callback code that will build the test suite. I'm talking about calls toit
but also functions that may loop over tables or files to declare a bunch of tests (by callingit
in the loop).Put inside hooks the code that actually initialize the state that the tests depend on.
All other considerations are quite secondary.
Let me explain...
The Background
Mocha executes a test suite in two phases:
It discovers what tests exist. During this phase it will immediately execute the callbacks passed to
describe
and record for future invocation the callbacks passed to the functions that declare tests (it
and the like) and functions that declare hooks (before
,beforeEach
,after
, etc.).It runs the tests. In this phase it will run the callbacks that it recorded earlier.
The Difference
So consider this example:
Note that
fullTitle
gives the whole name of a test starting from the top leveldescribe
, going through any nesteddescribe
down to theit
or hook that contains the call. Run with thespec
reporter and keeping only therunning:
lines, you get:Note the order of the hooks, and how each executes immediately before the tests declared in its respective
describe
callback.Consider then this suite:
Run with the
spec
reporter and keeping only therunning:
lines, you get:Note how both calls to
directDump
are run before anything else.The Consequences
If any initialization code that you put directly inside a callback to
describe
fails, the entire run fails right away. No test will be executed. End of story.If any initialization code that you put inside a
before
hook fails, the consequences are contained. For one thing, because abefore
hook is run just at the moment is needed, there is an opportunity any tests that are scheduled earlier can run. Also, Mocha will only skip those tests that depend on thebefore
hook. For instance, let's assume this suite:If you run it with the
spec
reporter, the entire output (minus the stack trace) will be something like:Note how a) some tests ran before the failing hook and b) Mocha still ran the tests that do not depend on the hooks.
Semantics, at both the machine and human level.
Also, it keeps test code in line with the "exports" interface, e.g.,
There's a couple different reasons why you might opt for the
before()
hook in your tests:Semantics
This is probably the biggest one. Sometimes you may need to perform a task, such as populate some dummy data in your database, prior to running an actual test. You can certainly do that in the test itself, but that throws off your reporting if you encounter an error while pre-populating, and before having run the actual test case at all. By having a
before()
hook, you have a logical, semantically valid place to insert this kind of logic.Cleaner for Async Tests
Just like mocha tests can be asynchronous, so can your
before()
hook logic. Going back to the pre-population example, this is handy since that means all of your async pre-test logic won't force another level of indentation on all of your actual testing logic.Consistency with other hooks:
Mocha also provides several other hooks, namely:
after()
,beforeEach()
, andafterEach()
. You could probably ask this same question about all these other hooks as well, but if you buy into the notion that any of them have a validated existence, thenbefore()
really needs to be included to round out the API.