Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature proposal: global setup and teardown #1460

Closed
tmpfs opened this issue Dec 3, 2014 · 16 comments
Closed

Feature proposal: global setup and teardown #1460

tmpfs opened this issue Dec 3, 2014 · 16 comments
Labels
type: feature enhancement proposal

Comments

@tmpfs
Copy link

tmpfs commented Dec 3, 2014

When testing a server code base and wishing to generate code coverage via an external tool such as istanbul it does not make sense to start and stop the server for every test suite using before and after - especially if there are a lot of test suites and the server performs various operations when starting.

I propose adding the ability to configure a setup function to be invoked asynchronously before any tests are executed and a teardown function after all test suites have been executed.

Whilst I have read CONTRIBUTING.md and imagine this feature is unlikely to be accepted as it may not be a common use case, I have implemented, tested and integrated this functionality with a real project, full details are in the (squashed) commit:

https://github.com/socialally/mocha/commit/fd744e480fa4acbc0846cdaa41f866034bdd38ab

If the consensus is that this feature would be useful to other people and a PR would be accepted then I will issue a PR with the linked commit.

@boneskull
Copy link
Member

@freeformsystems This has been asked for before (#1403); our take was that are reasonable workarounds.

The reason we aren't accepting many PRs at the moment is simply that we don't have enough resources to maintain more code.

This may be a handy feature, but unless there is no viable workaround, I can't see it getting merged soon. If you wish to contribute, I could use comments/suggestions on #1457--once that is in place, you wouldn't need code in Mocha core to get this working for you.

@travisjeffery
Copy link
Contributor

it's not just that we don't have the resources. it's also to keep mocha as simple as possible, and it's api small.

this feature does sound useful however i think so i'm not ruling it out.

@boneskull
Copy link
Member

(@travisjeffery Keeping Mocha simple is great, and if we can provide users with an API to build with if they do want some fancy feature, everybody will be happy. Right now I see a lot of disgruntled users because they have no recourse other than a PR.)

I'll reopen this.

@boneskull boneskull reopened this Dec 3, 2014
@travisjeffery
Copy link
Contributor

ya we having an api is clearly the best thing for everyone

@tmpfs
Copy link
Author

tmpfs commented Dec 5, 2014

@boneskull, checked out #1403. The solution spawning processes before and after doesn't help with my code coverage, adding gulp to the stack just for this seems unnecessary when every testing framework I have used has this functionality.

As far as I am aware this is very, very standard functionality for executing tests and think it should be included in mocha (although fully aware my implementation is crude).

With regard to #1457 I would love to help but am really stacked with commercial work at the moment, however having looked around the code a bit it appears to me there are no tests for the browser based test-runner - is that correct? If so the first thing I would do before any refactoring is improve the test suite (integrate with karma) and check the code coverage.

I have thought a little about the plugin refactoring and will try to add some comments soon.

@boneskull boneskull added the type: feature enhancement proposal label Dec 11, 2014
@oveddan
Copy link
Contributor

oveddan commented Dec 12, 2014

I also requested something similar in #1370. This would be great - especially for cleaning up mocks/stubs, or verifying that all expectations were run.

@danielstjules
Copy link
Contributor

Isn't this functionality already possible using the global suite's hooks?

$ cat setup.js
before(function() {
  console.log('global setup');
});

after(function() {
  console.log('global teardown');
});

$ cat test.js
describe('suite', function() {
  it('test', function() {});
});

dstjules:~/git/mocha (master=)
$ mocha test.js setup.js

global setup

  ․global teardown


  1 passing (10ms)

@tmpfs
Copy link
Author

tmpfs commented Apr 17, 2015

@danielstjules,

That looks good if it works, I'll check it out. Interestingly your example output does not show the test suite being executed (test.js)? Does mocha accept multiple [file] arguments i think it is a single glob pattern?

@danielstjules
Copy link
Contributor

Mocha handles both glob patterns and explicitly listing file arguments.

And the output above is showing the test suite being executed, but I used the dot reporter. Note the dot before the second "global". Here's with the spec reporter:

$ mocha --reporter spec test.js setup.js


global setup
  suite
    ✓ test

global teardown

  1 passing (10ms)

I'm thinking we could update the docs to make it known that this is possible. :)

@boneskull
Copy link
Member

@danielstjules I think I saw that in there the other night when I was working on the jekyll stuff.

@danielstjules
Copy link
Contributor

screen shot 2015-04-18 at 10 51 25 am

You're right - just found it under the asynchronous code section. It might be worth emphasizing in another section, or in the wiki somewhere.

@danielstjules
Copy link
Contributor

Closing for now, as the root before() and after() hooks seem to satisfy the requirements. :)

@danawoodman
Copy link

If I'm not mistaken, having a global before/after will get called for each describe block, is that correct? If so, how could one run something once before and once after the entire test suite runs (not for each describe)? Eg connect to a db when the suite starts (and block until connected) and disconnect after done

@danielstjules
Copy link
Contributor

If I'm not mistaken, having a global before/after will get called for each describe block, is that correct?

Nope, just at the start/end of the test suite :)

before(function() {
  console.log('before');
});

after(function() {
  console.log('after');
});

describe('suite1', function() {
  it('test', function() {});
});

describe('suite2', function() {
  it('test', function() {});
});
before
  suite1
    ✓ test

  suite2
    ✓ test

after

  2 passing (9ms)

@colinjoy
Copy link

colinjoy commented Oct 10, 2016

sorry for necromancing on this issue:
is this behaviour specific to the bdd interface? using tdd (loaded via karma-mocha) I observe that setup/teardown at the root level are invoked for every suite and every test. Quite the opposite of what is desired here.

edit:
after some more digging through issues, it turns out that the equivalents of before and after for tdd are suiteSetup and suiteTeardown

bors bot added a commit to IMA-WorldHealth/bhima that referenced this issue Dec 1, 2017
2321: Write unit tests for topic.js r=jeremielodi a=jniles

This PR adds tests for the topic.js library, a pub-sub system based on ioredis.

First, I have added a global setup function and teardown function (which is empty currently) for the server-unit tests.  These functions pre-load the environmental variables and setup up Chai with spies and promises.  These are located in `setup.js` in the `test/server-unit` directory.  See mochajs/mocha#1460 (comment) for the suggestion for this code.

Second, I've added unit tests to the topic library.  They use a spy plugin for chai to detect when callbacks have been fired.  Unfortunately, due to bugs with the `chai-spies` library (chaijs/chai-spies#78) I've had to use [chai-spies-next](https://www.npmjs.com/package/chai-spies-next).  In order to wait for the asynchronous code to complete, each spied function returns a
promise that determines when the testing should proceed.  If no actionhappens withing mocha's default timeout, the test fails.

Closes #2314.
@JamesMcMahon
Copy link

Isn't this functionality already possible using the global suite's hooks?

$ cat setup.js
before(function() {
  console.log('global setup');
});

after(function() {
  console.log('global teardown');
});

$ cat test.js
describe('suite', function() {
  it('test', function() {});
});

dstjules:~/git/mocha (master=)
$ mocha test.js setup.js

global setup

  ․global teardown


  1 passing (10ms)

That works pretty well in most scenarios, anyone have any idea how to run those before and after hooks in watch mode?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature enhancement proposal
Projects
None yet
Development

No branches or pull requests

8 participants