Don't call afterEach within beforeEach

[amcasey]

Otherwise, a new afterEach handler is added for each test case and the number of handlers run grows quadratically (wrt the number of tests in the suite adding the handlers).

[amcasey]

Before this change, 247177 hooks were executed; after, 152329.

[weswigham]

Other than numbers of handlers and repeatedly adding handlers being unneeded, does this have some kind of perf impact?

[amcasey]

@weswigham Unclear. Handlers are slower in the module transformation branch and at least part of the problem is that they run more handlers. I'm guessing it has to do with this bug and test ordering, but I'm still investigating. I don't expect any immediate perf win in main though.

[amcasey]

In the module transformation branch, there were 2,883,032 runs before and 151,826 after. Seems like a win. 😄

Edit: And test runtime in that branch dropped from ~1200s to ~795s.

[rbuckton]

I can't recall if it was jest or mocha, but one of them actually recommends you use afterEach inside of beforeEach, so I find this surprising.

[amcasey]

@rbuckton My guess was that it was leftover from our previous jest (?) usage. I reviewed a bunch of mocha samples and couldn't find any doing it this way and the trace of hook executions looks a lot more sensible after the change (typically, two before hooks and two after hooks for each test).

[amcasey]

Also note that, if the old form was correct, some of our other hooks would need updating in the other direction.

[rbuckton]

We've never previously used jest, just mocha.