by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 24 17:07
    nicojs synchronize #4234
  • Apr 24 16:55
    juergba unlabeled #4251
  • Apr 24 15:47
    Daniel0113 edited #4219
  • Apr 24 15:45
    Daniel0113 edited #4219
  • Apr 24 15:11
    Daniel0113 synchronize #4219
  • Apr 24 14:01
    juergba labeled #4227
  • Apr 24 14:01
    juergba unlabeled #4227
  • Apr 24 14:01
    juergba unlabeled #4227
  • Apr 24 13:58
    juergba edited #4251
  • Apr 24 13:33
    juergba labeled #4251
  • Apr 24 12:52
    juergba milestoned #4251
  • Apr 24 12:52
    juergba labeled #4251
  • Apr 24 12:52
    juergba labeled #4251
  • Apr 24 12:52
    juergba labeled #4251
  • Apr 24 12:51
    juergba assigned #4251
  • Apr 24 12:51
    juergba review_requested #4251
  • Apr 24 12:51
    juergba opened #4251
  • Apr 24 12:37

    juergba on karma

    type check before calling retri… (compare)

  • Apr 24 06:26
    juergba labeled #4250
  • Apr 24 06:26
    juergba labeled #4250
Luis Vegerano
@lvegerano
No I will try that
Yes I do require files
Chris NeJame
@SalmonMode
ok, so I've got an async function and I'm trying to test that it is rejected when a particular error is thrown in it. How do I check that an error of that particular type was thrown?
Craig Taub
@craigtaub
I think chai-as-promised can help there. Has a myPromise.should.be.rejectedWith(Error);
Chris NeJame
@SalmonMode
ah, so I have to use should on the promise object itself
I'll try that now
Chris NeJame
@SalmonMode
no dice TypeError: Cannot read property 'be' of undefined
here's the line of code promise.should.be.rejectedWith(StateNotSupportedError, 'Non-supported state');
Chris NeJame
@SalmonMode
figured it out
you were right regarding the syntax (althoguh .should is still being janky for me, so I used expect())
turns out I needed Object.setPrototypeOf(this, StateNotSupportedError.prototype); in my error's constructor to "repair the prototype chain"
more modern version of that line would be Object.setPrototypeOf(this, new.target.prototype);
Luis Vegerano
@lvegerano
anyone know why ncy tries to cover the test file and not the required file?
Luis Vegerano
@lvegerano
I have a set of test where I call a function (passing an instance of sinon) to initialize a handful of stubs. In afterEach I'm calling sinon.restore() but that is not reseting the stubs created with that function. I have to manually reset each stub. I don't think I should have to but I could be wrong. Here is an example https://hastebin.com/kerovecawi.js
Paul Jiang
@PaulJiang2021
I have a module named _mocha and another one named mocha
when I use mocha nothing prints in console
but _mocha seems to work
Does anyone know why this is the case?
Stuart Barclay
@Stuey61296
image.png
I have been struggling with this for a few hours and have no idea how to fix it.. Can anyone help...
Craig Taub
@craigtaub
@Stuey61296 how do u call mocha? do u reference logs/access.log in a relative path anywhere in ur code which mocha might run?
@PaulJiang2021 are those modules the real mocha or something u have created? How do u call it?
Stuart Barclay
@Stuey61296
@craigtaub I had a logs/access.log that was using morgan for logging, I moved the folder from the root into a sub-directory and it seemed to have fixed the problem!
Craig Taub
@craigtaub
cool
Jogiter
@Jogiter

how to write mocha test that have timeout and async both

createStream need to get permission of browser's video&audio,so i have to delay this test

both createStream and destroyStream return promise

i want to test destroyStream, this just not get what i want, anyone Help?

it("my test need to be delayed, and i want to test destroyStream", function () {
  setTimeout(async () => {
    // i need to create stream first
    const publishStream = await createStream();
    expect(streamCenter.previewVideoList.length).to.equal(1);

    // then destory stream
    await zg.destroyStream(publishStream);
    expect(streamCenter.previewVideoList.length).to.equal(0);
  }, 2000); // my test need to be delayed
});
Craig Taub
@craigtaub
U need to tell mocha to wait. Either return promise or call callback. See async test doc https://mochajs.org/#asynchronous-code. Also timeout usage https://mochajs.org/#timeouts
Andrew Slack
@andyslack

Hi Guys,

I am just getting into TDD and am really enjoying Mocha.

I am trying to setup my tests outside the /test/ folder inside my project following the naming convention File.test.js

I am struggling to get mocha to pick them up. I can point to a specific depth in my packags.json:

"test": "mocha / / *.test.js --config .mocharc.js"

But this will not pickup tests deeper.

Any ideas how I can specify this in the config, currently:

'use strict';

module.exports = {
diff: true,
extension: ['js'],
package: './package.json',
reporter: 'spec',
slow: 75,
timeout: 2000,
ui: 'bdd',
'watch-files': [' / / *.test.js'],
'watch-ignore': ['node_modules'],
recursive: true,
watch: true
};

Alex J Burke
@alexjeffburke
I think you’re looking for a glob pattern like ./**/*.test.js to recurse through all sub-directories
^ thats supposed to be two asterisks next to each other
Andrew Slack
@andyslack
Thanks Alex, is there a way to set this inside the config file? It does it have to be passed in console/via package.json?
Juerg B.
@juergba
@andyslack you can use the spec property, see docs
Jack Murphy
@rightisleft
Howdy - my test suit just started logging out a ton of verbose data about http calls etc - is there a way to turn that down?
Not sure why this suddenly became so verbose...
Christopher Hiller
@boneskull
@rightisleft I replied on SO
Christopher Hiller
@boneskull
Taylor Engel
@tengel92
I could use some help executing multiple test cases in serial. Basically having an issue "chaining" test cases together. I want to be able to execute spec files individually with one mocha --config .mocharc.single.js and one mocha --config .mocharc.multiple.js. However each spec file starts with a login and since mocha is "chaining" them together it will not not terminate the window session after each file completes even though I feel like it should be as the browser.quit() is in the after block but doesn't get executed.
.mocharc.multiple.js
var argv = require('yargs').default(
  'CURRENT_DATETIME_FOLDER',
  new Date(Date.now())
    .toISOString()
    .replace(/\:/g, '-')
    .replace(/\./g, '-')
    .slice(0, -1)
).argv;

module.exports = {
  bail: true,
  parallel: false,
  timeout: 25 * 60 * 1000, // 25 minute timeout
  spec: ['dist/examples/*.js'],
  reporter: 'node_modules/mochawesome',
  'reporter-option': [
    'reportDir=./reports/' + argv.CURRENT_DATETIME_FOLDER,
    'charts=true',
    'timestamp=true',
    'code=true',
  ],
};

Examples of test spec files
dist/examples/test1.js

import { pages } from '../specs-v5/mocha-hooks';

describe('User needs to sign in', () => {
  it('login', async () => {
    await pages.login.signInAsLocalUser();
  });

  it('Logic for 1', async () => {
    // Logic for 1
  });
});

dist/examples/test2.js

import { pages } from '../specs-v5/mocha-hooks';

describe('User needs to sign in', () => {
  it('login', async () => {
    await pages.login.signInAsLocalUser();
  });

  it('Logic for 2', async () => {
    // Logic for 1
  });
});
The only thing I can think of to do right now is a bit of a hacky workaround is to put an if block wrapping the login but there should be something better than that right?
Christopher Hiller
@boneskull
@tengel92 I’m not sure I follow, but something is still running which causes mocha to stay open. if your after() (I don’t see it in the example) is not being called, then Mocha is getting stuck on a test somewhere. you might want to use the default reporter for now, as I think mochawesome might trap the output?
Sean Poulter
@seanpoulter
Hey folks, is there a way to override the default describe? I wanted to wrap it to add a prefix to the test suite title. I've found #2737 but I'm not sure where to get a reference to the running framework from a required file or root hook. It seems straight forward to add a mocha.suite.on('pre-require',... otherwise. Thanks!!
Craig Taub
@craigtaub
Could create a slim 3rd party reporter, extending the Reporter you like, which prints a longer title (https://github.com/mochajs/mocha/wiki/Third-party-reporters). Or a 3rd party UI.
Sean Poulter
@seanpoulter
Thanks for steering me back on track Craig. :grinning:
David Ryan Hall
@RyanMG
Sorry if this comes up often, but I am not having no luck dealing with the async timeout error. I am testing code that not only runs async, but the size of the data the code needs to process means it can take up to 6 seconds to complete.
I can resolve the issue using the timeout overrides from the document, but that feels arbitrary - e.g. I am hardcoding a number of something that is meant to take an unspecified amount of time to complete. A test failure could just as well mean the timeout was not long enough as mean there is an actual code issue.

The documents listing using a "done" call to mark the run as complete, but doing this in the ways shown in documentation and people's examples online net no change in response.
It is entirely possible I am just doing something wrong here. This is a sample of a situation where I see the error:

const asyncCall = () => {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve(1);
    }, 5000);
  })
}

describe('defaultSettersGetters.js', function() {
  it('should work', async function() {
    const resp = await asyncCall();
    expect(resp).to.equal(1);
  });
});

This fails with the "Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves." message logged.

If I update the test to pass "done" in as an argument then call it, no change

const asyncCall = () => {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve(1);
    }, 5000);
  })
}

describe('defaultSettersGetters.js', function() {
  it('should work', async function(done) {
    const resp = await asyncCall();
    expect(resp).to.equal(1);
    done();
  });
});

What silly thing am I getting wrong here?

Peter Müller
@Munter
Stick with the async solution. Your problem is simply that your test is slower than mochas default timeout. The only thing you can do is specify a different timeout, or disable the timeout check completely
David Ryan Hall
@RyanMG
Ok thanks