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
Richard Littauer
@RichardLitt
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string or an instance of Buffer or URL. Received undefined. I don't understand where this error is coming from.
Got it.
The issue was that I needed to define where Mocha was testing. The test script calling 'mocha' in the package.json should probably be changed to 'mocha test/*js.'. https://mochajs.org/#getting-started
Amit Krishna
@amitkrishna
I am getting this error: '
'''UnhandledPromiseRejectionWarning: ElementClickInterceptedError: Element <button id="__button2" > is not clickable at point (1124,66) because another element <div id="shieldlayer-id-1600148583053-10" class="UiPopupShield"> obscures it''''
While running selenium with mocha How to fix this?
Craig Taub
@craigtaub
@amitkrishna that depends on your setup i guess, sounds like a selenium error. Im afraid w/o seeing code all I can suggest is checking your setup is correct against our example (https://github.com/mochajs/mocha-examples/tree/master/packages/selenium).
Pavlin Stoenchev
@pavlin117_gitlab
Hello Everyone, does someone know why my tests exit with code 0 when there is actually a failed test ?
rembeckyb
@rembeckyb_twitter

Is it possible to print a variable in an "it" statement title? For example:

describe("Get Build Version", function () {

    let buildVersion;

    it("Retrieve build version", function () {
        buildVersion = common.getBuildVersion();
        expect(buildVersion).to.not.equal('undefined');
    });

    it("Build Version: " + buildVersion, function () {
        expect(buildVersion).to.not.equal('undefined');
    });
}

However, the printed buildVersion in the second "it" statement title shows as undefined, despite properly retrieving the build version. The tests pass fine, and console.log(buildVersion) shows the variable has its intended value, but still the "it" statement title shows as undefined.
How can I have it show the proper variable value?

rembeckyb
@rembeckyb_twitter

I've changed to this code based off a solution I found online, but it still doesn't work.

describe("Get Build Version", function () {

    let buildVersion;

    it("Retrieve build version", function () {
        buildVersion = common.getBuildVersion();
        expect(buildVersion).to.not.equal(false);
    });

    it("Build Version: ", function () {
        this.test.title = this.test.title + buildVersion;
        console.log(this.test.title);
        expect(buildVersion).to.not.equal(false);
    });
}

Even stranger is that the console.log(this.test.title); prints properly, but the test title is still reported as simply "Build Version: ". What am I doing wrong?

Craig Taub
@craigtaub
@rembeckyb_twitter its relating to the ordering mocha runs a suite. With test titles + using a variable. The variable could be set in “before”/“beforeEach" hooks or the “describe" context itself, but not in a test. Abit of info on https://mochajs.org/#run-cycle-overview, it runs the test functions last.
Lukas Wilkeer
@lukaswilkeer

HI folks, I'm having trouble using beforeEach hook. A can't define a variable calling a function.

The code is:

let user;
let db;

beforeEach(async () => {
  const password = generatePassword('******')

  user = {
    account_type: 0,
    email: '*****@*****.com',
    password: password,
    name: 'Lukw',
    last_name: 'wilkerson',
    permission: 1
  }

  db = await model
})

The error is: Error message

Causing a type error: Cannot read property 'password' of undefined

Craig Taub
@craigtaub
Wheres the error thrown from? a test or the model thing? Could do with more info + code. How is user used?
Lukas Wilkeer
@lukaswilkeer
The generatePassword doens't apply, so the variabel hosts a mocha function that sandboxes that thing, in theory should works, generatePassword is a mocha utility function that returns a md5 string, obviously is synchronous.
chan-ai
@chan-ai
Is there a way I can add annotation 'defect' on mocha framework? I am using wdio-junit-reporter and would like to link the defect id to the failed test
Full Stack Ruby on Rails Developer
@webdev778
hi
Stephen
@StephenGit_gitlab

Hey all, I am struggling with getting thrown errors to output to the console. I have tests running and they just exit with no details. eg:

LocationGraphQL...
npm ERR! code ELIFECYCLE
npm ERR! errno 1

There is no stack trace at all. I did set fullTrace to true. Please let me know if any more info is needed, just wondering at this point if there is perhaps a setting to force showing error output

Lukas Wilkeer
@lukaswilkeer

@craigtaub the error comes from assign variables before the it and inside the describe. The beforeEach is called when and test (it) is executed, before this, the variables doesn't get setted.

I'm think in how to reuse the same variables configurations accross multiples test cases, but the mocha provides only one solution, that's is: the global setted variables using hooks is only provided on test cases, not before.

So, I will need to declared the same code on each test case.

Lukas Wilkeer
@lukaswilkeer

@craigtaub Currently I'm attempt to set a callsFake method on a MongoDB native driver findOne function. There's one questio: if a function receives a param and a callback I'm just neet do do: .callsFake((params, callback) => callback(null, user));

The pattern of mongdo db native driver is error, content, so, calling the callback solves the issue, right?

The issue is, the console.log of the callback and data on findOneStub and findOne method, simply is undefined.
logikbyran
@logikbyran
hi! i'm very very new to mocha. does anyone know a simple way to assert that a (keydown) event handler (inside a React component, in my case), did Not call event.preventDefault?
Peter Müller
@Munter
Depends on your level of test. You could construct a fake event with a preventDefault method that is a sinon spy and assert that it was not called when you send it to the event handler.
Or you could test a full user interaction and add an event listener for the same even on a parent element and assert that event.defaultPrevented is false
Or you could test for the side effect that you expected to happen when default was not prevented
logikbyran
@logikbyran
the first suggestion sounds good

the code base (react-autosuggest) already uses React's Simulate.keyDown(input, { key: 'ArrowDown', keyCode: 40 }); in the other tests

i'd prefer to keep using that for consistency... hmm

Dave Schinkel
@dschinkel
I've spent a whole day on the above so any help would be highly appreciated..I'm quite frustrated with it.

@logikbyran

hi! i'm very very new to mocha. does anyone know a simple way to assert that a (keydown) event handler (inside a React component, in my case), did Not call event.preventDefault?

If your components are not using React Hooks, bypass the DOM and just call your event handler directly. I know people are going to automatically throw the "you're testing implementation details flag" but that's cargo cult and IMO BS in this case if I prefer as a developer, the public contract under test not to be webdriver or jsdom or the browser, and to be custom functions I choose to be part of my public API to test that behavior directly. Not it won't test your keydown but so what, you'll see that won't work immediately when you fire up the app. It's not a regression worth spending time requiring you to go through heavy tests just to test that wiring.

Dave Schinkel
@dschinkel

@rembeckyb_twitter I'd highly recommend not to name tests that way. Just don't, you're causing yourself more hell and people reading the tests hell and maintenance hell later on by doing so.

The point here is: Well formed tests. That means keep implementation details like technical words, function names, and worse variables out of your test names as test names should describe behavior in well written prose, not the how. That how or outcome should only be part of your test implementation details, so keep it there, not in your test names. Your test names should explain behavior, not "how" what's under test is derived. Let the assertion speak as to why or why it did not pass.

PoodleSkirt
@PoodleSkirt2_twitter

Hi all, I'm having a lot of trouble running mocha on some typescript tests on a single file.

My file structure is like this:

current_directory [
     app.test.ts
    nested_directory [
      auth.test.ts
    ]
]

The trouble is, when I run the command mocha --exit --require ts-node/register app.test.ts, I'm expecting it to run only the tests in app.test.ts, but somehow it's also attempting to run tests in auth.test.ts (that's weird thing #1), and those tests are failing (weird thing #2).

This is the error:

  auth controller
    1) "before all" hook for "can log in existing user"
    2) "after all" hook for "fails to log in non-existent user"

  App
express tracing might not work as /Users/cohenkarnell/selected/schoolfit/server/node_modules/express/index.js was loaded before the trace agent was initialized.
mongodb-core tracing might not work as /Users/cohenkarnell/selected/schoolfit/server/node_modules/mongodb-core/index.js was loaded before the trace agent was initialized.
(node:26674) DeprecationWarning: collection.ensureIndex is deprecated. Use createIndexes instead.
Sep 30, 15:54:28:596 pm
user: unknown uid
/
    ✓ returns 200 when accessing an existing route that has no auth requirements (993ms)
Sep 30, 15:54:29:578 pm
user: unknown uid
/totally-fake-route-that-will-never-exist
    ✓ returns 404 when accessing a non-existent route (111ms)
    3) "after all" hook for "returns 404 when accessing a non-existent route"


  2 passing (5s)
  3 failing

  1) auth controller
       "before all" hook for "can log in existing user":
     TypeError: app_1.default is not a function
      at Context.<anonymous> (controllers/auth.test.ts:21:14)
      at process.topLevelDomainCallback (domain.js:126:23)

  2) auth controller
       "after all" hook for "fails to log in non-existent user":
     Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/cohenkarnell/selected/schoolfit/server/app.test.ts)

I have no configuration file.

I've narrowed the problem of the tests failing down to an import statement in the auth tests returning {} instead of the correct object which I don't understand, but my bigger concern is, why is it picking up the tests in the nested directory when I didn't specify --recursive??

Mocha version is 8.1.3

I am super happy to try out anything anyone suggests, I am very much banging my head against the wall atm. I'm also new to testing with node so I'm hoping it's something pretty obvious.
PoodleSkirt
@PoodleSkirt2_twitter
Okay, I figured out that the tests can be made to pass by converting the import from a default import to a named import in the source directory (there was seemingly no actual syntax error here though - maybe an issue with my tsconfig.json)
I still don't get why both test files are running though when I specify exactly one test file in the outer directory
PoodleSkirt
@PoodleSkirt2_twitter
I figured it out, some test files were being imported by some code that shouldn't have been importing them, causing them to be run, which also caused cyclic imports, causing them to fail. What a nightmare
adhusson
@adhusson

Hi! I'm trying to dynamically generate tests. There's a framework which calls

      testFiles.forEach((file) => mocha.addFile(file));

      const runPromise = new Promise<number>((resolve, _) => {
        mocha.run(resolve);
      });

      process.exitCode = await runPromise;

My test files need to await some information and then use that info to generate it() tests. Is there a way to do that without changing the framework code?

adhusson
@adhusson
For now I'm solving my issue with https://github.com/ForbesLindesay/sync-rpc
Mihail
@MihailPertsev
Hi everyone! I have a quick question: Where can I find all reporter options for all 9 default reporters?
Время Упадка
@9I2Aoqcvx7JWcbT_twitter
image.png
Hello everyone! How possible this thing in pipeline? I can't understand this
Herman Stoud Platou
@hpl002

Hi gang!

Have searched in the docs but cannot seem to find a description or example of what i am trying to do. However, im pretty sure its supported as its such a trivial case.

How can i run and report on all tests while also passing arguments to the tests themselves?

Each test case requires a path to a config. I want to run and report on all configs, but then i naturally have to specify their path.

What would be the way forward with that?

Alex Miller
@fotoflo
Hi guys!
Is it possible to change the port mocha allows the debugger to attach on?
mocha --debug=9228 --watch --inspect test/**/*.test.js
Debugger listening on ws://127.0.0.1:52851/49b1e489-3705-458f-b098-8912ccb4a10c
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Starting inspector on 127.0.0.1:9229 failed: address already in use
Waiting for the debugger to disconnect...
Juerg B.
@juergba
@fotoflo The debug flags are not Mocha flags. They are Node options, which Mocha passes over to Node. The correct options are --inspect-port=[host:]port or --inspect[=[host:]port], I guess. I haven't done any testing. You can also pass these Node options via NODE_OPTIONS directly to Node.
nthn h
@nthn.h_gitlab
Hi everyone, has anyone come across any issues running mocha tests with an MQTT client. Currently my setup works, the prelim tests are all passing, but the test runner doesn't exit after all the tests are ended. There is no complex code, just connecting to the MQTT server causes the problem and when I comment that line out, the process exits correctly after all tests are complete. I will appreciate any help. Thanks.
Juerg B.
@juergba
@nthn.h_gitlab can't you disconnect within an after hook? Or just use the --exit option.
nthn h
@nthn.h_gitlab
Since I am not testing the client object explicitly, it is undefined in the after hook so I cannot disconnect it. According to SO, it's not recommended to force tests to exit, as it could reveal underlying memory issues. The unit tests have nothing to do with MQTT so far, the function I am testing just lives in the same page so I don't understand why it isn't exiting.
PoodleSkirt
@PoodleSkirt2_twitter
Hi friends, I'm having and issue where I want to be able to run tests written in typescript, but it fails if there are type errors. I'd like it to output the type errors, but still run the tests. This is the command I'm using to run the tests: mocha --exit --require ts-node/register. Does anyone know how I can get it to show type errors but still run tests? Thanks for any help!
PoodleSkirt
@PoodleSkirt2_twitter
Maybe the question I'm asking is, can I pass the --log-error argument to ts-node somehow when running mocha so it only logs type errors instead of throwing them?
PoodleSkirt
@PoodleSkirt2_twitter
Urigee
@another_malcolm_twitter
Hello. I’m utilizing grep functionality to mark some of my tests as a specific suite (I’m not using suites itself because I already have 500+ tests and they are already structured, so I didn’t want to change anything). I’m marking some of my tests with specific markers like “@smoke”, “@mobile” etc. At this point, I have around 5 markers and the issue is that my reports started to look really ugly. What I’m trying to achieve is to edit the test names. I want to this before running the test but after grep fetched all the required tests.
I’m able to get access to the this.test.title or this.currentTest.title but no luck on actual editing the test names.
The only one time it was successful in this scenario:
A before hook inside the describe block.
Inside the hook: this.currentTest.title = ‘Name is changed!’
But since the before hook runs only once, it is changing the name of the first test in the suite only.
Can someone help me to figure out at what point and how can I edit the test name. And most important to not affect the grep functionality by doing so. (Maybe I’m taking the wrong way and I should look into after hooks...)
Michael Dahl
@micdah
I see a version 9.0.0 mentioned in the MochaJS documentation, but I cannot seem to find anywhere to get this version? Latest is 8.2.0
Specifically regarding the global fixtures: https://mochajs.org/#global-fixtures
It looks like the global fixtures are actually added in 8.2.0, so maybe the documentation is just wrong?
JeongHoon Byun (a.k.a Outsider)
@outsideris
The document is wrong, we changed to release it in 8.2.0, but we didn't update the document.
we will fix it.