Revise before and after options that were added in v1.4.0

[balupton]

I forgot to ask why adding them was a good idea, as knowing why, we can be able to come up with better solutions, without knowing why, we just know what, and we can't change what.

#5 (comment)

[balupton]

Completed this with https://github.com/bevry/joe/blob/9115d8608f1ee6707b96ffba74d57c8ca5db340b/src/example/example1.coffee#L66-L100

@pflannery @christav is this good by you?

[christav]

Seems good to me. One question: how does it interact with nested suites? My default expectation if I have an outer suite and an inner suite with tests in each, that the behavior would be:

For test in outer suite:
Outer test.before
Outer test
Outer test.after

For tests in inner suite:
Outer test.before
Inner test.before
Inner test
Inner test.after
Outer test.after

Also, any chance of getting "suite.before" and "suite.after" events as well?

[balupton]

Yeah suite after and suite before are there too, not tests yet for them.

Currently for inner items, they do not inherit their parent/outer events. How essential is that?

[christav]

I think the nested ordering is important.

1. Every other tool that I know of works this way, so having joe not support nested before/after would be confusing and surprising.
2. The whole point of nesting suites is to help organize them into groups, and part of that organization is centralizing setup and teardown, both on the per suite and per test level.
3. When writing BDD style given/when/then tests, I use the nested before features all the time.

To expand on #3, when writing Given/When/Then style tests (I tend not to go to cucumber unless there's going to be a big investment, but I find it really useful as a way to organize my thoughts/tests), I'll often set up my tests something like (mocha like example):

describe('Given some initial conditions', function () {
  var state;
  beforeEach(function () {
    suite = someSetup();
  });

  describe('When this thing happens', function () {
    beforeEach(function ()) {
      state.doThisThing();
    });

    it('then has blah', function () {
      expect(state.blah).something();
    });

    it('then has been floobled', function () {
    ....
    });
  });

  describe('When other thing happens', function () {
    beforeEach(function () {
      state.doOtherThing();
    });

    it('then is in other state', function () {
      ...
    });
  });
});

Hope that makes sense. I find it a really useful style, and without predictable and nested ordering for before/after functions I can't do it.

[balupton]

does beforeEach in the above example also run before each suite, or only before each test

[christav]

Sorry, using Mocha terminology. beforeEach is the equivalent of your "test.before" event. "before" is the "suite.before" event. So no, beforeEach does not run before each suite, only before each test.

However, the "suite.before" events should act in a similar manner - outer's suite.before should fire, then run outer's tests, then inner.before should fire, then inner's tests should run, etc.

[balupton]

I'll probably introduce a new event for nesting something like nested.test.before maybe

[balupton]

Done with the nested.(test|suite).(before|after) style. Just need to write tests now.

[balupton]

Does mocha's beforeEach and afterEach functions support completion callbacks? If not, this makes what joe does even more awesome, as we do.

[balupton]

A few commits ago, I also re-added support for the before and after configuration options of @pflannery's original way of accomplishing this. Which is good, as I can just bump this to a minor release once all the tests are done, as it is b/c compatible.

[christav]

Yes, mocha provides completion callbacks for before, beforeEach, after, and afterEach. Sorry. :-)

[balupton]

Joe v1.5 and TaskGroup v4 released which now accomplish this :)