chaijs / chai-fs Goto Github PK

In my case, this is causing issues with chai-spies. For example, this passes fine:

let spies = require("chai-spies");
let fs = require("chai-fs");
let chai = require("chai");

chai.use(fs).use(spies);

let { spy, expect } = chai;

it("should still let me use chai-spies' .with() assertions", async () => {
	let fn = spy((arg) => arg + 1);

	let x = fn(2);

	expect(x).to.equal(3);
	expect(fn).to.have.been.called.once;
	expect(fn).to.have.been.called.with(2);
});

But this fails:

let spies = require("chai-spies");
let fs = require("chai-fs");
let chai = require("chai");

chai.use(spies).use(fs); // <--- the only change is the order on this line

let { spy, expect } = chai;

it("should still let me use chai-spies' .with() assertions", async () => {
	let fn = spy((arg) => arg + 1);

	let x = fn(2);

	expect(x).to.equal(3);
	expect(fn).to.have.been.called.once;
	expect(fn).to.have.been.called.with(2);
});

Output:

  1) should still let me use chai-spies' .with() assertions:
     TypeError: expect(...).to.have.been.called.with is not a function
      at Context.it (spec.js:18:37)

When using both chai-fs and chai-as-promised, promises start returning before being handled, kind of like when you run an async test without done.

I'm not sure which side the issues sits with so have raised it on both

Example test:

const chai = require('chai')
const expect = chai.expect
chai.should()
chai.use(require('chai-as-promised'))
chai.use(require('chai-fs'))

describe('resolve', function(){

  it('expect', function(){
    return expect( Promise.resolve('two') ).to.eventually.equal('one')
  })

  it('should', function(){
    return Promise.resolve('two').should.eventually.equal('one')
  })

})       

Results in promises being rejected but not handled by mocha:

○ → mocha

  resolve
    ✓ shouldn't resolve
(node:79302) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): AssertionError: expected 'two' to equal 'one'
    ✓ shouldn't resolve
(node:79302) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): AssertionError: expected 'two' to equal 'one'


  2 passing (16ms)

Swapping the order and loading chai-fs first:

chai.use(require('chai-fs'))
chai.use(require('chai-as-promised'))

Results in the normal promise handling behaviour:

○ → mocha

  resolve
    1) expect
    2) should


  0 passing (16ms)
  2 failing

  1) resolve expect:

      AssertionError: expected 'two' to equal 'one'
      + expected - actual

      -two
      +one
      
      at getBasePromise.then.then.newArgs (node_modules/chai-as-promised/lib/chai-as-promised.js:302:22)

  2) resolve should:

      AssertionError: expected 'two' to equal 'one'
      + expected - actual

      -two
      +one
      
      at getBasePromise.then.then.newArgs (node_modules/chai-as-promised/lib/chai-as-promised.js:302:22)

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The devDependency grunt was updated from 1.0.4 to 1.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

grunt is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Is this the right behavior ?

 // existentDir is a directory that exists
 expect(existentDir).to.be.a.directory() => true, ok
// nonExistentDir is a directory that doesn't exists
expect(nonExistentDir).to.not.be.a.path() => true, ok
expect(nonExistentDir).to.not.be.a.directory() => false ?  

If a directory doesn't exist shouldn't "to.not.be.a.directory()" gives false?
Thanks !

A check for symlinks could be useful. As a starting point, this is what I'm currently using (CoffeeScript):

fs = require('fs')

module.exports = (chai, utils) ->

  # expect(path).to.be.a.symlink()
  # expect(path).not.to.be.a.symlink()
  chai.Assertion.addMethod 'symlink', ->

    try
      isSymlink = fs.lstatSync(this._obj).isSymbolicLink()
    catch err
      # If it doesn't exist, it's clearly not a symlink
      if err.code == 'ENOENT'
        isSymlink = false
      else
        throw err

    this.assert(
      isSymlink,
      'expected #{this} to be a symlink',
      'expected #{this} not to be a symlink'
    )

The package chai does not satisfy its siblings' peerDependencies requirements!
peerinvalid Peer [email protected] wants chai@>= 1.6.1 < 2

I'll look into fixing this up with a pull request right now.

The comment on

This choice should be documented (it was a surprise when it failed in Windows tests during CI).

Bonus points: making this overridable with a configuration option somewhere (e.g. usePathSep or something to that effect, whose default value would result in the current behavior) would ensure existing tests still work, but people writing code intended for multiple OSes can write tests more easily if they choose to use path.join in their test code.

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The devDependency underscore was updated from 1.9.2 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

underscore is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Any chance this could be updated to work with Chai 3.4.0 please?

Thanks

The comment on

I disagree with the stance taken, but I understand why it was done. Instead of changing it (a breaking change), I propose making it overridable with an option - e.g. usePathSep or something to that effect (whose default value would result in the current behavior).

In addition Further, the current behavior should be documented.

.to.not.be.a.file() does not work, returns true, even if the file is not existing, example:

expect( path.join( __dirname, './tmp/lessReduce/root.css' ) ).to.not.be.a.file();

... but the file is definitely not there ... but throws an asserting exception.

So for one of my test cases, my setup process (before() hook) is to copy a directory from one place to another. My application code is then supposed to analyze the copied location and either modify files in that directory or not based on params, so I'm working on testing behavior against a range of inputs.

Without actually running my application code yet, I decided to test chai-fs's behavior to make sure that I am using the right assertion, so that if I don't get what I expect I at least know it's my app code and not the assertion library that's causing me grief.

Well... here's how that worked out.

As I said I did a full directory copy from 'a' to a new directory 'b'. I visually inspected to make sure file 'filename' exists in both directories and it looks identical visually. If I run:

expect('./a/filename').to.be.a.file('It is a file').and.equal('./b/filename', 'Nope, files are not the same');

I get an assertion error that the expectation failed (and the second message is the one that shows up). Not sure how these two files can have different content when the one file was copied unmodified from the other file just before the test.

Any idea how to debug this, or is this feature not fully implemented yet?

The current version on npm is 0.1.0 which still has a peer dependency on chai < 2. Chai is up to 3.5 now. I know I can just reference the master branch, but updating npm would be value add for developers.

When using the following line, Webstorm's debugging of mocha tests fails with an exit code of 130.

chai.use(require('chai-fs'))

The only workaround I've found thus far is to remove chai-fs from my unit tests.

Logs:

/usr/local/bin/node --debug-brk=54452 /usr/local/lib/node_modules/mocha/bin/_mocha --timeout 259200000 --ui bdd --reporter /Applications/WebStorm.app/Contents/plugins/NodeJS/js/mocha-intellij/lib/mochaIntellijReporter.js /Users/username/Documents/project/test/simple-test.js --grep "simple test$"
Debugger listening on port 54452

Process finished with exit code 130

Node: v5.6.0
Chai: v3.5.0
Chai-fs: v0.1.0

I'm trying to write an assertion checking that a directory exists and contains some files. Here's what I have:

expect(path).to.be.a.directory().and.include.files(fileList);

When the tests run, it throws a TypeError:

     Uncaught TypeError: expect(...).to.be.a.directory(...).and.include.files is not a function
      at Test.<anonymous> (test/integration/site.spec.js:47:58)
      at Test.assert (node_modules/supertest/lib/test.js:161:6)
      at Server.assert (node_modules/supertest/lib/test.js:131:12)
      at emitCloseNT (net.js:1525:8)
      at _combinedTickCallback (internal/process/next_tick.js:71:11)
      at process._tickCallback (internal/process/next_tick.js:98:9)

When I remove the additional .and.include.files chain, the test passes successfully:

expect(path).to.be.a.directory();

It seems there may have been some kind of regression around the directory() function. I pulled down the project and ran the tests manually. It stopped after 32 failed tests and they all seem to relate to the directory function.

-> failed 32 and passed 967 of 999 tests, left 28 pending (723ms)

Is this a problem with my local environment? Can anyone else reproduce this behavior?

Thanks

Hi Guys,

This is not actually an issue, just wondering what am I suppose to pass in data in this code?

expect(path).to.be.a.file(?msg).with.content(data, ?msg);

correct me if I'm wrong:

1. path - file path
2. ?msg - text that I'm looking for
3. data - ?

I can't see it in the documentation, if it is there, I'm sorry please send me the link.

Thanks!

The chai-fs package on npm hasn't been updated since the project was transferred from @Bartvds to @chaijs/chai two years ago. 😩

@keithamus - Not sure what exactly needs to be done to get the npm package updated. I'm happy to help if I can.