Code Monkey home page Code Monkey logo

chai-immutable's Introduction

npm Version License Build Status Build Status Coverage Status devDependencies Status peerDependencies Status

Chai Immutable

This plugin provides a set of Chai assertions for Facebook's Immutable library for JavaScript collections.

Assertions

Installation

Node.js

Install via npm or yarn:

npm install --save-dev chai-immutable
yarn add --dev chai-immutable

You can then use this plugin as any other Chai plugins:

const chai = require('chai');
const chaiImmutable = require('chai-immutable');

chai.use(chaiImmutable);

ES6 syntax (needs Babel transpiling)

import chai from 'chai';
import chaiImmutable from 'chai-immutable';

chai.use(chaiImmutable);

In the browser

Include this plugin after including Chai and Immutable. It will automatically plug in to Chai and be ready for use:

<script src="chai-immutable.js"></script>

Using chai-immutable with other plugins

If you are using this plugin with chai-as-promised or dirty-chai, note that chai-immutable must be loaded before any of them. For example:

const chai = require('chai');
const chaiAsPromised = require('chai-as-promised');
const chaiImmutable = require('chai-immutable');
const dirtyChai = require('dirty-chai');
const { expect } = chai;

chai.use(chaiImmutable);
chai.use(chaiAsPromised);
chai.use(dirtyChai);

const { List } = require('immutable');

/* ... */

expect(Promise.resolve(List.of(1, 2, 3))).to.eventually.have.size(3);
expect(true).to.be.true();

BDD API Reference (Expect / Should)

.empty

Asserts that the immutable collection is empty.

expect(List()).to.be.empty;
expect(List.of(1, 2, 3)).to.not.be.empty;

.equal(collection)

  • @param { Collection } collection

Asserts that the values of the target are equivalent to the values of collection. Aliases of Chai's original equal method are also supported.

const a = List.of(1, 2, 3);
const b = List.of(1, 2, 3);
expect(a).to.equal(b);

Immutable data structures should only contain other immutable data structures (unlike Arrays and Objects) to be considered immutable and properly work against .equal(). See issue #24 for more information.

Also, note that deep.equal and eql are synonyms of equal when tested against immutable data structures, therefore they are aliases to equal.

.referenceEqual(value)

  • @param {Collection} value

Asserts that the reference of the target is equivalent to the reference of collection. This method preserves the original behavior of Chai's equal.

See issue #210 for more details.

const a = List.of(1, 2, 3);
const b = a;
const c = List.of(1, 2, 3);
expect(a).to.referenceEqual(b);
expect(a).to.not.referenceEqual(c);

.include(value)

  • @param { Mixed } val

The include and contain assertions can be used as either property based language chains or as methods to assert the inclusion of a value or subset in an immutable collection. When used as language chains, they toggle the contains flag for the keys assertion.

Note that deep.include behaves exactly like include in the context of immutable data structures.

expect(new List([1, 2, 3])).to.include(2);
expect(new List([1, 2, 3])).to.deep.include(2);
expect(new Map({ foo: 'bar', hello: 'world' })).to.include('bar');
expect(new Map({ a: 1, b: 2, c: 3 })).to.include(new Map({ a: 1, b: 2 }));
expect(new Map({ foo: 'bar', hello: 'world' })).to.include.keys('foo');

.keys(key1[, key2[, ...]])

  • @param { String... | Array | Object | Collection } keyN

Asserts that the target collection has the given keys.

When the target is an object or array, keys can be provided as one or more string arguments, a single array argument, a single object argument, or an immutable collection. In the last 2 cases, only the keys in the given object/collection matter; the values are ignored.

expect(new Map({ foo: 1, bar: 2 })).to.have.all.keys('foo', 'bar');
expect(new Map({ foo: 1, bar: 2 })).to.have.all.keys(new List(['bar', 'foo']));
expect(new Map({ foo: 1, bar: 2 })).to.have.all.keys(new Set(['bar', 'foo']));
expect(new Map({ foo: 1, bar: 2 })).to.have.all.keys(new Stack(['bar', 'foo']));
expect(new List(['x', 'y'])).to.have.all.keys(0, 1);

expect(new Map({ foo: 1, bar: 2 })).to.have.all.keys(['foo', 'bar']);
expect(new List(['x', 'y'])).to.have.all.keys([0, 1]);

// Values in the passed object are ignored:
expect(new Map({ foo: 1, bar: 2 })).to.have.all.keys({ bar: 6, foo: 7 });
expect(new Map({ foo: 1, bar: 2 })).to.have.all.keys(
  new Map({ bar: 6, foo: 7 })
);
expect(new List(['x', 'y'])).to.have.all.keys({ 0: 4, 1: 5 });

Note that deep.property behaves exactly like property in the context of immutable data structures.

By default, the target must have all of the given keys and no more. Add .any earlier in the chain to only require that the target have at least one of the given keys. Also, add .not earlier in the chain to negate .keys. It's often best to add .any when negating .keys, and to use .all when asserting .keys without negation.

When negating .keys, .any is preferred because .not.any.keys asserts exactly what's expected of the output, whereas .not.all.keys creates uncertain expectations.

// Recommended; asserts that target doesn't have any of the given keys
expect(new Map({ a: 1, b: 2 })).to.not.have.any.keys('c', 'd');

// Not recommended; asserts that target doesn't have all of the given
// keys but may or may not have some of them
expect(new Map({ a: 1, b: 2 })).to.not.have.all.keys('c', 'd');

When asserting .keys without negation, .all is preferred because .all.keys asserts exactly what's expected of the output, whereas .any.keys creates uncertain expectations.

// Recommended; asserts that target has all the given keys
expect(new Map({ a: 1, b: 2 })).to.have.all.keys('a', 'b');

// Not recommended; asserts that target has at least one of the given
// keys but may or may not have more of them
expect(new Map({ a: 1, b: 2 })).to.have.any.keys('a', 'b');

Note that .all is used by default when neither .all nor .any appear earlier in the chain. However, it's often best to add .all anyway because it improves readability.

// Both assertions are identical
expect(new Map({ a: 1, b: 2 })).to.have.all.keys('a', 'b'); // Recommended
expect(new Map({ a: 1, b: 2 })).to.have.keys('a', 'b'); // Not recommended

Add .include earlier in the chain to require that the target's keys be a superset of the expected keys, rather than identical sets.

// Target object's keys are a superset of ['a', 'b'] but not identical
expect(new Map({ a: 1, b: 2, c: 3 })).to.include.all.keys('a', 'b');
expect(new Map({ a: 1, b: 2, c: 3 })).to.not.have.all.keys('a', 'b');

However, if .any and .include are combined, only the .any takes effect. The .include is ignored in this case.

// Both assertions are identical
expect(new Map({ a: 1 })).to.have.any.keys('a', 'b');
expect(new Map({ a: 1 })).to.include.any.keys('a', 'b');

The alias .key can be used interchangeably with .keys.

expect(new Map({ foo: 1 })).to.have.key('foo');

.property(path[, val])

  • @param { String | Array | Iterable } path
  • @param { Mixed } val (optional)

Asserts that the target has a property with the given path.

expect(new Map({ a: 1 })).to.have.property('a');

When val is provided, .property also asserts that the property's value is equal to the given val. val can be an immutable collection.

expect(new Map({ a: 1 })).to.have.property('a', 1);

Note that deep.property behaves exactly like property in the context of immutable data structures.

Add .nested earlier in the chain to enable dot- and bracket-notation when referencing nested properties. An immutable List can also be used as the starting point of a nested.property.

expect(Immutable.fromJS({ a: { b: ['x', 'y'] } })).to.have.nested.property(
  'a.b[1]'
);
expect(Immutable.fromJS({ a: { b: ['x', 'y'] } })).to.have.nested.property(
  'a.b[1]',
  'y'
);
expect(Immutable.fromJS({ a: { b: ['x', 'y'] } })).to.have.nested.property(
  ['a', 'b', 1],
  'y'
);
expect(Immutable.fromJS({ a: { b: ['x', 'y'] } })).to.have.nested.property(
  new List(['a', 'b', 1]),
  'y'
);

If . or [] are part of an actual property name, they can be escaped by adding two backslashes before them.

expect(Immutable.fromJS({ '.a': { '[b]': 'x' } })).to.have.nested.property(
  '\\.a.\\[b\\]'
);

Add .not earlier in the chain to negate .property.

expect(new Map({ a: 1 })).to.not.have.property('b');

However, it's dangerous to negate .property when providing val. The problem is that it creates uncertain expectations by asserting that the target either doesn't have a property at the given path, or that it does have a property at the given key path but its value isn't equal to the given val. It's often best to identify the exact output that's expected, and then write an assertion that only accepts that exact output.

When the target isn't expected to have a property at the given path, it's often best to assert exactly that.

expect(new Map({ b: 2 })).to.not.have.property('a'); // Recommended
expect(new Map({ b: 2 })).to.not.have.property('a', 1); // Not recommended

When the target is expected to have a property at the given key path, it's often best to assert that the property has its expected value, rather than asserting that it doesn't have one of many unexpected values.

expect(new Map({ a: 3 })).to.have.property('a', 3); // Recommended
expect(new Map({ a: 3 })).to.not.have.property('a', 1); // Not recommended

.property changes the target of any assertions that follow in the chain to be the value of the property from the original target object.

expect(new Map({ a: 1 }))
  .to.have.property('a')
  .that.is.a('number');

.size(value)

  • @param { Number } size

Asserts that the immutable collection has the expected size.

expect(List.of(1, 2, 3)).to.have.size(3);

It can also be used as a chain precursor to a value comparison for the size property.

expect(List.of(1, 2, 3)).to.have.size.least(3);
expect(List.of(1, 2, 3)).to.have.size.most(3);
expect(List.of(1, 2, 3)).to.have.size.above(2);
expect(List.of(1, 2, 3)).to.have.size.below(4);
expect(List.of(1, 2, 3)).to.have.size.within(2, 4);

Similarly to length/lengthOf, sizeOf is an alias of size:

expect(List.of(1, 2, 3)).to.have.sizeOf(3);

TDD API Reference (Assert)

.equal(actual, expected)

  • @param { Collection } actual
  • @param { Collection } expected

Asserts that the values of actual are equivalent to the values of expected. Note that .strictEqual() and .deepEqual() assert exactly like .equal() in the context of Immutable data structures.

const a = List.of(1, 2, 3);
const b = List.of(1, 2, 3);
assert.equal(a, b);

Immutable data structures should only contain other immutable data structures (unlike Arrays and Objects) to be considered immutable and properly work against .equal(), .strictEqual() or .deepEqual(). See issue #24 for more information.

.referenceEqual(actual, expected)

  • @param {Collection} actual
  • @param {Collection} expected

Asserts that the reference of actual is equivalent to the reference of expected. This method preserves the original behavior of Chai's equal.

See issue #210 for more details.

const a = List.of(1, 2, 3);
const b = a;
const c = List.of(1, 2, 3);
assert.referenceEqual(a, b);
assert.throws(() => assert.referenceEqual(a, c));

.notEqual(actual, expected)

  • @param { Collection } actual
  • @param { Collection } expected

Asserts that the values of actual are not equivalent to the values of expected. Note that .notStrictEqual() and .notDeepEqual() assert exactly like .notEqual() in the context of Immutable data structures.

const a = List.of(1, 2, 3);
const b = List.of(4, 5, 6);
assert.notEqual(a, b);

.notReferenceEqual(actual, expected)

  • @param {Collection} actual
  • @param {Collection} expected

Asserts that the reference of actual is not equivalent to the reference of expected. This method preserves the original behavior of Chai's notEqual.

See issue #210 for more details.

const a = List.of(1, 2, 3);
const b = a;
const c = List.of(1, 2, 3);
assert.throws(() => assert.notReferenceEqual(a, b));
assert.notReferenceEqual(a, c);

.sizeOf(collection, length)

  • @param { Collection } collection
  • @param { Number } size

Asserts that the immutable collection has the expected size.

assert.sizeOf(List.of(1, 2, 3), 3);
assert.sizeOf(new List(), 0);

chai-immutable's People

Contributors

antonin-arquey avatar astorije avatar dependabot[bot] avatar dmonego avatar greenkeeper[bot] avatar gugu avatar jakelazaroff avatar jakubzitny avatar matthewwithanm avatar meeber avatar renovate-bot avatar scottnonnenberg avatar slobo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

chai-immutable's Issues

Should there be support for a .frozen property?

I found myself in the need to test if an object was frozen.

Right now, one has to do:

expect(Object.isFrozen(obj)).to.be.true;

which is not very pretty. I came up with a simple helper to allow the following syntax:

expect(obj).to.be.frozen;

I am not sure if this helper should be part of this project. On one end, it's not using Immutable, but on the other end, Object#freeze() is the closest we have to immutable objects in JS...

So, should I include it here? Any other suggestion?

Use ES6 in the documentation

Not sure if the code should go for ES6 yet, but we could at least start with examples from the documentation. If so, then maybe the test suite should be moved to ES6 to reflect the documentation too.

assert.notEqual passes when 2 different objects have the same values

The following test fails (see this build):

var list3 = List.of(1, 2, 3);
var deepMap = new Map({ foo: 'bar', list: List.of(1, 2, 3) });
var sameDeepMap = new Map({ foo: 'bar', list: List.of(1, 2, 3) });

it('should fail given equal values', function () {
  assert.throws(function () { assert.notEqual(list3, List.of(1, 2, 3)); }, Error);
});

it('should fail given deeply equal values', function () {
  assert.throws(function () { assert.notEqual(deepMap, sameDeepMap); }, Error);
});

This shows that assert.notEqual needs to be overriden to take into account equality between values even though the underlying objects are different.

Add a Code of Conduct

Upstream Chai project has added a Code of Conduct (chaijs/chai#565) so it would be a good idea to add it here as well.
Easy to do if someone wants to give it a shot.

Write comprehensive tests for `.not.property`

Meaning of .not.property changes between Chai v3 and v4 (see chaijs/chai#744) and as pointed out by #69, currently tests aren't breaking for any version.

There needs to be tests proving .not.property works properly on v3 and breaks on v4, so the v4 transition can be done smoothly.

(This is not a chai v4 issue because it does not require Chai v4, it's the other way around.)

JSCS rules on comments are too strict

According to this comment by @matthewwithanm, it's not possible to leave comments like:

// Lorem ipsum dolor sit amet
// consectetur adipiscing elit

But only:

/*
 * Lorem ipsum dolor sit amet
 * consectetur adipiscing elit
 */

Which is quite painful! I think I went a bit too far on comment conventions and I need to relax them a bit...

Support List and Map as input for the keys assertion

It is currently possible to give an Array of keys and an Object of keys to the keys assertion, but considering the library we are testing against, it would be a shame to not be able to use List and Map elements.

Should I allow other input types too (Set, ...) ? Should I be more generic instead (like testing against KeyedCollection instead of Map, ...)?

Add namespace info in doc strings

Not sure how the new site will or will not leverage this, but chai-immutable should reproduce chaijs/chai#552 for consistency.

It is a very easy thing to add if someone wants to get some GitHub contribution, otherwise I'll do that within the next few weeks when I have a bit of time to spend on chai-immutable.

Feature request: comparison of Maps via include

In vanilla Chai, you can assert that a JS object includes all properties (and values) of another obj
i.e.

expect({a: 1, b: 2, c: 3}).to.include({b: 2, c: 3});

Would it be possible to add a similar feature to chai-immutable for comparing Maps?

Potentially isSuperset could be used(?), or perhaps each key/value pair would need to be compared individually.

Vanilla chai behaviour, for reference: https://jsbin.com/cihiteyoyu/2/edit?html,js,output

not.key passes when the key is not part of the collection

The following test fails (see this build):

var map = new Map({ x: 1, y: 2 });
var obj = { x: 1, y: 2 };

it('should fail using `not` given an inexisting key', function () {
  expect(function () { expect(map).to.not.have.key('x'); }).to.throw(Error);
  expect(function () { expect(obj).to.not.have.key('x'); }).to.throw(Error);
});

Map equality issue

Hi,

First of all, it appears (and it makes sense) that key order in an immutable Map with primitive fields does not matter, as illustrated by the following test:

  it('Key order for Maps with primitive fields does not matter', ()=>{
    const simpleMap =  Map({
      loaded: false,
      working: true
    });    
    expect(simpleMap).to.equal(Map({   // key order different
      working: true,
      loaded: false
    }));
  })

However, if an immutable Map contains one or more key with plain object in it will cause equality to fail if the order of keys is different, as illustrated in the following test (notice I use to.eql, not to.equal):

  it('Map field data order matters!!', ()=>{
    const map =  Map({
      loaded: false,
      working: true,
      message: {first_name: 'john', last_name: 'due'}
    });
    expect(map).to.eql(Map({   // key order the same
      loaded: false,
      working: true,
      message: {first_name: 'john', last_name: 'due'}
    }));
    expect(map).to.eql(Map({   // key order different
      working: true,
      loaded: false,
      message: {first_name: 'john', last_name: 'due'}
    }));
  })

The second expect fails.

Is that an intended behavior or a bug in chai-immutable?

Thanks,
Alex

PS. I am using chai-immutable v. 1.3.0.

Add support for chai-as-promised

I have some promises returning collections from immutable.js.
It'd be nice to expect the promised values with chai-as-promised.

Something like:

expect(Promise.resolve(immutable.List())).to.eventually.be.empty

Publish new version!

There are several commits which are not published to NPM.

One really important to me is 7c8697f

Can you please publish them?

Thank you.

Check support of browserify

I have never used browserify so I am not sure if chai-immutable is compatible with it out of the box or if any additional work is needed.

That'd be great if someone can test this and give a report here.

Immutables nested in vanilla js objects are not compared properly

Hi there, I'm working on unit tests for a Redux application and I'm trying to compare two so called "actions" which are objects that looks something like this:

action = {
    type: 'myType',
    list: myImmutableList
}
expectedAction = {
    type: 'myType',
    list: anIdenticalList
}

This happens:

console.log(action.type === expectedAction.type); // true
console.log(action.list.equals(expectedAction.list)); // true
expect(action.list).to.equal(expectedAction.list); // works
expect(action).to.equal(expectedAction); // throws AssertionError, as it should
// BUT
expect(action).to.deep.equal(expectedAction); // throws AssertionError, this is unexpected

I'm new to Immutable but so I'm not sure, but this looks like a bug to me? Thanks

Drop support of Node v0.10 and v0.12

Maintenance of v0.12 stops in 31 December 2016, and maintenance of v0.10 has already stopped. Additionally, Chai v4 will drop these as well.

This will allow for lots of ES6 features, such as arrow functions at the very least.

This is a backward-incompatible change though, so this will be a major version bump.

`not` in assertions is ignored

Given the following assertion:

expect(fromJS({ x: 1})).to.not.have.key('y');

I get the following result:

AssertionError: expected 'Map { "x": 1 }' to have key 'y'

So it seems that the not statement in the assertion is ignored.

I am using:

mocha 2.4.5
chai 3.5.0
chai-immutable: 1.5.4

Records compare equal to Maps

See original discussion here:
glenjamin/transit-immutable-js#13 (comment)

Notable points:

var FooRecord = Immutable.Record({ a: 1, b: 2 }, 'foo');

// This assertion passes
expect(new FooRecord()).to.eql(new Immutable.Map({a: 1, b: 2}));

// Because this is true
Immutable.is(new FooRecord(), new Immutable.Map({a: 1, b: 2}));

And this is currently by design: https://twitter.com/glenathan/status/688050710047539200

I think it'd be useful to provide a way to opt into a stricter comparison in chai-immutable. I'm unsure whether or not I think it should be the default at this point.

One suggested approach is to say that immutable object should be both equal, and stringly equal - as records include their names in the string output. This doesn't handle records with the same name though - so perhaps it would need something more complicated.

/cc @corbt

Problem deep comparing two immutable Lists

Given a couple of immutable lists with identical items in some instances I've had problems when deep comparing them in my tests using the chai-immutable plugin.

  expect(Immutable.is(listOne, listTwo)).to.equal(true); // works ok
  expect(listOne).is.eql(listTwo); // fails

Collections should be deeply traversable

dot-and-bracket notation can be used for Array and Object elements.
A similar thing should be possible with Immutable collections.

var deepMap = new Map({
  green: new Map({ tea: 'matcha' }),
  teas: List.of('chai', 'matcha', new Map({ tea: 'konacha' }))
});

expect(deepObj).to.have.deep.property('green.tea', 'matcha');
expect(deepObj).to.have.deep.property('teas[1]', 'matcha');
expect(deepObj).to.have.deep.property('teas.[2].tea', 'konacha');

Specific syntax to define (I may prefer to use obj.get(prop) instead of obj.prop to reflect the library's API).

Make chai-immutable compatible with AMD loaders

I was initially planning to support it, but removed support completely in 46ea795 as it is clear it will not work as is.

I have no idea how AMD loaders nor RequireJS work as I'm not using them myself, so I'd be glad if someone can step in and provide a fix.
Probably not a lot to do, but not something I am intending to focus on myself, at least in the near future.

Comparison of Lists fails on different internal properties

Hello. Apologies if this has been addressed or if I've done something foolish, but I'm pretty sure this is legitimately unexpected behavior.

I'm using Immutable 3.7.5, Chai 3.4.1 and chai-immutable 1.5.3 with Node 4.2.2 on Windoze. Here's what I'm seeing:

    describe('A List', () => {

        function addListItem(currentState,item) {
            // Push item onto currentState and return the new state
            return currentState.push(item);
        }

        it('is immutable', () => {
            let state = List.of('Bar','Foo');
            let nextState = addListItem(state, 'Baz');

            expect(nextState).to.equal(List.of(
                'Bar',
                'Foo',
                'Baz'
            ));
        });

    });

I expect this test to pass, however:

AssertionError: expected List [ "Bar", "Foo", "Baz" ] to equal List [ "Bar", "Foo", "Baz" ]
      + expected - actual

       {
      -  "__altered": true
      +  "__altered": false
         "__hash": [undefined]
         "__ownerID": [undefined]
         "_capacity": 3
         "_level": 5
             "Bar"
             "Foo"
             "Baz"
           ]
      -    "ownerID": {}
      +    "ownerID": [undefined]
         }
         "size": 3
       }

These internal implementation properties "ownerID" and "__altered" are resulting in a failed assertion that I believe should pass.

Add Sauce Labs support

Spent some time on this tonight, not sure how to do that.
Is it possible to setup Sauce Labs so that tests are run in different browsers?
Right now they are just run in phantomjs, it would be nice to know if they pass on all browsers or not.
Any help on that will be appreciated.

Add support for custom messages

First of, is this a desired feature?

@ulrikhindoe started working on this at #85 but it never got in simply because I wasn't responsive enough.
If anyone wants to help with this, I'll be more careful :)

No issue.

my bad dude, didn't mean to create this

assert.equal doesn't give nice output if truncate threshold is reached

Consider this assertion:

        assert.equal(Immutable.Set([Immutable.Map({ id: "one", propName: "subref" })]),
                     Immutable.Set([1, 2]));

This fails with this ugly error:

AssertionError: expected { Object (size, _map, ...) } to equal Set { 1, 2 }

I debugged why I sometimes got this kind of error. It's because the length of the string representation of the actual value exceeds Chai's truncate threshold. Chai then proceeds to fall back to another method and displays the object in a truncated fashion.

I don't think it looks like Chai's objDisplay function can be easily taught about truncating Immutable.js's values. So I think it would be best to detect whether what we pass into actual (or expected) is an Immutable object, and if so, pass in the string instead of the object itself. It should then pass through without harm.

assert support is missing

I tried to use this plugin but was confused why it didn't work for "assert.equal". It turns out you need to install a bridging function on the "assert" object, see this mailing list entry:

https://groups.google.com/forum/#!topic/chaijs/Dwnbsbe0C70

I tried the following:

assert.equal = function(act, exp, msg) {
    new chai.Assertion(act, msg).to.equal(exp);
};

and now it works. The same should be done with the other overrides.

Add tests for failure cases

At the moment, only successful cases are tested (to detect false negatives, cases that fail although they should pass). This prevents us to detect false positives (cases that pass although they should fail).

Failing tests should be added, similarly to Chai's tests, see example here.

I already suspect one bug that can be proven with this, there might be more.

Add a custom assertion to retrieve a value at a specific key

Chai's dot-notation for property lets us do the following for Array and Object elements:

expect([1, 2, 3]).to.have.deep.property('[2]', 3);

Without more custom assertions for Immutable, I don't think we have an alternative to:

expect(List.of(1, 2, 3).get(2)).to.equal(3);

which causes a problem when using something like Chai as Promised because we end up with something not as straightforward as with Array elements.

// Assuming p promises us [1, 2, 3]
return expect(p).to.eventually.have.deep.property('[2]', 3);

// Assuming p promises us List.of(1, 2, 3)
return p.then(function (list) { return expect(list.get(2)).to.equal(3); });

A suitable solution would be an assertion that lets us do:

expect(List.of(1, 2, 3)).to.whatever(2, 3);

where its signature is whatever(key, value). This lets us use eventually:

// Assuming p promises us List.of(1, 2, 3)
return expect(p).to.eventually.whatever(2, 3);

An even better solution, IMO, would be:

expect(List.of(1, 2, 3)).to.whatever(2).equal(3);

so that we could have things like:

expect(List.of('abc', 'def', 'ghi')).to.whatever(2).contain('bc');
expect(List.of(1, 2, 3)).to.whatever(2).above(0);

Which idea seems best?
Any reasons why these would be bad ideas? If so, any better ideas?

Cannot find module 'immutable'

I am upgrading my package dependencies, including chai-immutable to 1.6.0, and I am getting this error upon running my code:

Error: Cannot find module 'immutable'
    at Function.Module._resolveFilename (module.js:527:15)
    at Function.Module._load (module.js:476:23)
    at Module.require (module.js:568:17)
    at require (internal/module.js:11:18)
    at Assertion (/Users/elliott/Documents/GitHub/onestop/client/node_modules/chai-immutable/chai-immutable.js:8:30)
    at Object.<anonymous> (/Users/elliott/Documents/GitHub/onestop/client/node_modules/chai-immutable/chai-immutable.js:18:2)

As far as I can tell, chai-immutable handles 'immutable' as a dependency in it's own package.json. So why is it barfing here, suddenly?

I have done a rm -rf on my node_modules directory and reinstalled via npm -i before running, for the record.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.