Giter VIP home page Giter VIP logo

expect.js's Introduction

Expect

Minimalistic BDD assertion toolkit based on should.js

expect(window.r).to.be(undefined);
expect({ a: 'b' }).to.eql({ a: 'b' })
expect(5).to.be.a('number');
expect([]).to.be.an('array');
expect(window).not.to.be.an(Image);

Features

  • Cross-browser: works on IE6+, Firefox, Safari, Chrome, Opera.
  • Compatible with all test frameworks.
  • Node.JS ready (require('expect.js')).
  • Standalone. Single global with no prototype extensions or shims.

How to use

Node

Install it with NPM or add it to your package.json:

$ npm install expect.js

Then:

var expect = require('expect.js');

Browser

Expose the index.js found at the top level of this repository.

<script src="expect.js"></script>

API

ok: asserts that the value is truthy or not

expect(1).to.be.ok();
expect(true).to.be.ok();
expect({}).to.be.ok();
expect(0).to.not.be.ok();

be / equal: asserts === equality

expect(1).to.be(1)
expect(NaN).not.to.equal(NaN);
expect(1).not.to.be(true)
expect('1').to.not.be(1);

eql: asserts loose equality that works with objects

expect({ a: 'b' }).to.eql({ a: 'b' });
expect(1).to.eql('1');

a/an: asserts typeof with support for array type and instanceof

// typeof with optional `array`
expect(5).to.be.a('number');
expect([]).to.be.an('array');  // works
expect([]).to.be.an('object'); // works too, since it uses `typeof`

// constructors
expect([]).to.be.an(Array);
expect(tobi).to.be.a(Ferret);
expect(person).to.be.a(Mammal);

match: asserts String regular expression match

expect(program.version).to.match(/[0-9]+\.[0-9]+\.[0-9]+/);

contain: asserts indexOf for an array or string

expect([1, 2]).to.contain(1);
expect('hello world').to.contain('world');

length: asserts array .length

expect([]).to.have.length(0);
expect([1,2,3]).to.have.length(3);

empty: asserts that an array is empty or not

expect([]).to.be.empty();
expect({}).to.be.empty();
expect({ length: 0, duck: 'typing' }).to.be.empty();
expect({ my: 'object' }).to.not.be.empty();
expect([1,2,3]).to.not.be.empty();

property: asserts presence of an own property (and value optionally)

expect(window).to.have.property('expect')
expect(window).to.have.property('expect', expect)
expect({a: 'b'}).to.have.property('a');

key/keys: asserts the presence of a key. Supports the only modifier

expect({ a: 'b' }).to.have.key('a');
expect({ a: 'b', c: 'd' }).to.only.have.keys('a', 'c');
expect({ a: 'b', c: 'd' }).to.only.have.keys(['a', 'c']);
expect({ a: 'b', c: 'd' }).to.not.only.have.key('a');

throw/throwException/throwError: asserts that the Function throws or not when called

expect(fn).to.throw(); // synonym of throwException
expect(fn).to.throwError(); // synonym of throwException
expect(fn).to.throwException(function (e) { // get the exception object
  expect(e).to.be.a(SyntaxError);
});
expect(fn).to.throwException(/matches the exception message/);
expect(fn2).to.not.throwException();

withArgs: creates anonymous function to call fn with arguments

expect(fn).withArgs(invalid, arg).to.throwException();
expect(fn).withArgs(valid, arg).to.not.throwException();

within: asserts a number within a range

expect(1).to.be.within(0, Infinity);

greaterThan/above: asserts >

expect(3).to.be.above(0);
expect(5).to.be.greaterThan(3);

lessThan/below: asserts <

expect(0).to.be.below(3);
expect(1).to.be.lessThan(3);

fail: explicitly forces failure.

expect().fail()
expect().fail("Custom failure message")

Using with a test framework

For example, if you create a test suite with mocha.

Let's say we wanted to test the following program:

math.js

function add (a, b) { return a + b; };

Our test file would look like this:

describe('test suite', function () {
  it('should expose a function', function () {
    expect(add).to.be.a('function');
  });

  it('should do math', function () {
    expect(add(1, 3)).to.equal(4);
  });
});

If a certain expectation fails, an exception will be raised which gets captured and shown/processed by the test runner.

Differences with should.js

  • No need for static should methods like should.strictEqual. For example, expect(obj).to.be(undefined) works well.
  • Some API simplifications / changes.
  • API changes related to browser compatibility.

Running tests

Clone the repository and install the developer dependencies:

git clone git://github.com/LearnBoost/expect.js.git expect
cd expect && npm install

Node

make test

Browser

make test-browser

and point your browser(s) to http://localhost:3000/test/

Credits

(The MIT License)

Copyright (c) 2011 Guillermo Rauch <[email protected]>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

3rd-party

Heavily borrows from should.js by TJ Holowaychuck - MIT.

expect.js's People

Contributors

amasad avatar aseemk avatar bramstein avatar hokaccha avatar janmarek avatar mikeando avatar nathanmacinnes avatar paulmillr avatar rauchg avatar rauno56 avatar satazor avatar slexaxton avatar timshadel avatar tj avatar tricknotes avatar vlazzle avatar wyattdanger avatar yourcelf 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  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

expect.js's Issues

Symlink infinite loop causes build tools to :/

There is a symlink, specifically: ./test/src --> ../

Even if you want to copy the directory, I get an error in the terminal:

directory causes a cycle

Any other solution to linking up the src directory like that? It'd really help!

Thanks!

expect({a: 1}).to.have.only.key('a') fails

It appears that have and only cannot be swapped:

expect({a: 1}).to.only.have.key('a') // this works
expect({a: 1}).to.have.only.key('a') // this doesn't

I would expect the second to work, given the documentation, but it fails.

Problematic Package Name

Two problems I've encountered relating to the name of this package:

1.) I easily overlooked that the function name didn't match the package so incorrectly attempted installing with npm install expect which is actually a different package. Once I got the correct package, I still tripped over having to assign the function to a variable with a different name in order to execute.

2.) I can't use the --require option of mocha with expect.js because the function name needs to match the package.

Proposal: Convince onirame to relinquish the name of expect to you. His module appears to be pretty thin and unmaintained for three months. A lesser alternative would be to rename the package and the calling function to something else like 'expectjs' or 'expectthis'.

Support comparison of boxed types

Since threequality obviously doesn't cover boxed natives, I expected .eql() to do so, but it doesn't:

expect( new String('foo') ).to.eql('foo')

Error: expected { '0': 'f', '1': 'o', '2': 'o' } to sort of equal 'foo'
 at Assertion.assert (โ€ฆproj/node_modules/expect.js/expect.js:99:13)
 at Assertion.eql (โ€ฆproj/node_modules/expect.js/expect.js:214:10)

Either .eql() should inherently support comparing boxed-types to natives, or we need a form of test that is directly equivalent to ==. At the moment, all I can do is the following, which is more than a little awkward:

expect( (new String('foo')) == 'foo' ).to.be.ok()

[Feature] Number of expected assertions

I think it is very useful to test for a number of assertions because in asynchronous tests it's a common error that callbacks are accidentally invoked multiple times.

Maybe this way:

expect(someValue).to.be.ok();
expect(someOtherValue).to.be.ok();

expect.numOfTests().to.be(2);

An internal counter counts the number of assertions. numOfTests() just matches the counter with the expected number. After numOfTests() is called the internal counter is reset.

One problem of that approach would be if testing suites run asynchronous tests in parallel. But I'm not sure if that is usual.

What do you think?

Way to Override Output Formatting

Currently if you do something like:

expect({foo:1}).to.be({foo:2});

you get output like:

expected {foo:1} to equal {foo:2}

That's great when you have only a single property on your object, but if your objects are full of properties (or even just have one property that's a really long string) the error output quickly becomes difficult to use.

It would be really handy if you could specify the output Expect.js should use. For instance, if the following lines:

if (value.toString) {
    return value.toString();
}

are added to "format" (inside the "i" function) then a user could do:

expect({
   foo:1
   longString: '...',
   toString: function() { 
      return 'foo ' + this.foo;
  }
}).to.be({
   foo:2
   longString: '...',
   toString: function() { 
      return 'foo ' + this.foo;
  }
});

and get the (much more useful) output:

    expected foo 1 to equal foo 2

(Of course, in a real world scenario that toString method would be defined on the class of our two objects, instead of on each object.)

Would it be possible to get something like this added to Expect.js?

Library Version 0.0.2 Available on NPM fails to load

Getting the following error with the currently released version:

Derp:website cheezburger$ mocha

/Users/cheezburger/Projects/website/node_modules/expect/expect.js:17
expect.version = '0.0.2';
^
ReferenceError: expect is not defined
at /Users/cheezburger/Projects/website/node_modules/expect/expect.js:17:3
at Object. (/Users/cheezburger/Projects/website/node_modules/expect/expect.js:75:2)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:362:17)
at require (module.js:378:17)
at Command. (/usr/local/lib/node_modules/mocha/bin/_mocha:151:3)
at Command.EventEmitter.emit (events.js:126:20)

Looks like the expect object is scoped to the export and not available in the module directly.

Expecting Null or Not Null Does Not Work

I can't seem to write a proper test for "null".

Example : Either of the tests below should fail but do not, right?

var response = { 
    "status": "failed",
    "errorType": "vendor",
    "error": "Unroutable message - rejected",
    "messageCount": "1",
    "to": "5555551212",
    "from": "5555551212",
    "messageId": null,
    "msgPrice": null
}

expect( response.msgPrice).not.to.be(null);
expect( response.msgPrice).to.not.be(null);

"Sub" object checking?

Hey there,

Great work on the library -- I really like it.

In writing tests against a REST API, I'd find it really convenient to check that response objects, which can have many properties and values, contain some particular properties and values.

@visionmedia's should.js has include() for this kind of thing, and it's really helpful:

https://github.com/visionmedia/should.js#includeobj

Here it might be e.g.:

expect(resp).to.include({
  name: 'John Smith',
  username: 'johnsmith',
  age: 29
});

But whereas should's include() is for checking presence in arrays and strings too, I see that expect has contain() for those. So maybe this could be added into contain(), but maybe not.

What do you think? Thanks!

retry until expectation meet or time out (async expectations)

I'm using expect.js for UI testing with headless browser. Nasty problem - JS UI is asynchronous, with delays, smooth UI transitions and so on. So, when You click button - the actual action may take place not immediately but after 0.2sec.

It makes testing hard - You has to repeatedly check and wait for some conditions, and code becomes hairy. One possible solution - incorporate wait and retry logic directly into expectation library. For example, below are two versions of code that does the same thing.

First version opens profile dialog, waits for it and checks for some field inside of it.

client.click('Profile')
var condition = function(){return client.hasDialog('Profile')}
waitFor(condition, function(){
  expect(client.text()).to.match(/Name:.*Jim Raynor/)  
  client.click('Messages')
  ...
})

But we can simplify it, we don't have to check explicitly for dialog to be opened, we can just check for what we are really interested in - presence of some specific field. So, we can rewritte match function to retry every 0.05sec and raise error only after 1sec timeout, and code will be greatly simplified:

client.click('Profile')
expect(client.text()).to.match(/Name:.*Jim Raynor/, function(){
  client.click('Messages')
  ...
})

It seems that such functionality may be done as an addon to expect.js - by wrapping all terminal
functions like match, eql, be, ... with async wait & retry wrapper. What do You think?

Loose equality checking for functions

Loose equality checking does not currently work with functions:

expect(function() {}).to.eql(function() {}); // throws

We could use the toString method of the function to check for equality. This would likely fall back to checking if both objects are functions in older browsers. Some engines perform transforms on the functions (like precomputing static operations), but they should do so consistently, so the functions would still come out the same.

Thoughts?

throwException fails in IE9

When throwing a new Error() from within a function that needs to be tested, and you have a test which runs to.throwException, everything is fine in current FF / Chrome.

IE9 fails - that is, it marks the test as red.

Promised support?

Heavily inspired by chai-as-promised
Instead of manually wiring up your expectations to a promise's fulfilled and rejected handlers:

doSumAsync(2, 2).then(
    function (result) {
        expect(result).be(4);
        done();
    },
    function (err) {
       done(err);
    }
);

you can write code that expresses what you really mean:

expect.promise(doSumAsync(2, 2).be(4).notify(done);

or if you have a testing framework that follows the UncommonJS specification for handling promises, simply

return expect.promise(doSumAsync(2, 2).be(4);

Do you think this feature should be in core, an extension, or a fork? And what about the api, should we use expect.promise(myPromise), or expect(myPromise) and expect checks duck-type for thenable.

Btw, I can work on this and make PR

`expect` return value can't be reused with `.to.have.property`.

Here's a minimal illustration in Mocha:

var expect = require("expect.js");
describe("", function() {
    specify("", function() {

        var y = expect({ a : 1, b : 2 });
        y.to.have.property("a", 1);         // This is OK.
        y.to.have.property("b", 2);         // Mocha outputs "Error: expected 1
                                            // to have a property 'b'".

    });
});

I'm reusing expect's return value. Why is expect.js expecting 1 to have a property b?

The issue seems to be with .to.have.property, as using other assertions works fine:

        var x = expect(1);
        x.to.be.equal(1);                   // This is OK.
        x.to.not.be.equal(0);               // This is OK too.

TypeError: Object explicit failure has no method 'call'

I don't completely know for sure whether this is a problem with Mocha or if it's a problem with expect.js but either way, whenever I explicitly fail, I get that message rather than whatever I have my fail message as.
Example:

test.js:

    describe('This is', function(){
        var dude = new Frankenstein($("body"), window); 
        it("a test that will fail", function(){
            expect().fail(" I, the test, did fail... therefore I passed. I am so meta.");
        });
     });

terminal:

$ mocha test.js
  .
  1 failing

  1) This is a test that will fail:
     TypeError: Object  I, the test, did fail... therefore I passed. I am so meta. has no method 'call'
      at Assertion.assert (/Users/aluhring/Sites/default/node_modules/expect.js/expect.js:99:27)
      at Assertion.fail (/Users/aluhring/Sites/default/node_modules/expect.js/expect.js:470:10)
      at Context.<anonymous> (/Users/aluhring/Sites/default/public/tests/_podder.js:99:22)
      at Test.Runnable.run (/usr/local/lib/node_modules/mocha/lib/runnable.js:211:32)
      at Runner.runTest (/usr/local/lib/node_modules/mocha/lib/runner.js:372:10)
      at /usr/local/lib/node_modules/mocha/lib/runner.js:448:12
      at next (/usr/local/lib/node_modules/mocha/lib/runner.js:297:14)
      at /usr/local/lib/node_modules/mocha/lib/runner.js:307:7
      at next (/usr/local/lib/node_modules/mocha/lib/runner.js:245:23)
      at Object._onImmediate (/usr/local/lib/node_modules/mocha/lib/runner.js:274:5)
      at processImmediate [as _immediateCallback] (timers.js:330:15)

Being that the test is supposed to fail and that the test is failing, I'm getting the result I need but I'm not trying to get a stack trace of an error that I want to exist... but that's what I'm getting.
Is there something I'm doing wrong or is this what's supposed to happen?
Any help or direction would be appreciated.

make test failed

jacksontian expect $ make test

module.js:340
    throw err;
          ^
Error: Cannot find module '../expect'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/jacksontian/git/expect/test/common.js:7:10)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at files (/Users/jacksontian/git/expect/node_modules/mocha/bin/_mocha:271:3)
    at Array.forEach (native)
    at Object.<anonymous> (/Users/jacksontian/git/expect/node_modules/mocha/bin/_mocha:270:10)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:902:3
make: *** [test] Error 8

TypeError: Property 'be' of object #<Assertion> is not a function

I feel like this has to be user error but here's what I'm seeing. Using expect.js 0.1.2 with chai and mocha.

The following produces an error:
expect(1).to.be(1);
TypeError: Property 'be' of object # is not a function

But if I do something like this it works:
expect(1).to.eql(1);

expect([]).to.eql({}) is true?

I believe it should not. Maybe you could compare the internal class name Object.prototype.toString.call(obj)? That would also fix #61 and #60. Thanks.

cyclic data

checking cyclic data for equality results in an infinite loop

Name conflict with another project

Somebody created an assertion library with the exact same name a few months ago and their NPM package is the top result when googling expect.js npm (And this one doesen't even show up on the first page). Their package name is expectjs (Without the period). Wasted time this am trying to figure out why my tests were broken only to realize I had pulled down their lib. I created an issue with them to either remove the NPM package or change the name of the project so it doesn't conflict but it might be a good idea to note it on the readme here.

Provide method for deep equivalence with type saftey.

Currently you can do is but that will ensure two objects are equal. It would be nice to have a way to ensure all values are equal and the correct type.

expect({a:5}).to.eql({a:"5"}); // Passes.

It would be nice to have this as I have objects with many properties and it is a pain to manually .is() check each property.

So it would be nice to have something that strictly compares types if "scalar" values (including strings). And recursively compares objects and Arrays.

Properties vs keys unification?

I think the modifiers should be:

  • only
  • own

And we should unify properties/keys. I think the distinction is hard to grasp by just reading tests or the function names.

Thoughts?

Approximate floating point value

Expect.js currently does not support ensuring a floating point number approximates another number within a certain accuracy. Proposed usage:

expect(0.99999).to.approximate(0.99998, 4); // works
expect(0.99999).to.approximate(0.99998, 5); // fails
expect(0.999999).to.approximate(0.999998, 5); // works
expect(0.999999).to.approximate(0.999998, 6); // fails

Assertion for comparing objects recursively with strict equality

Examples:

expect({ a: 3 }).to.equalRec({ a: '3' })  // fails
expect({ a: 3 }).to.equalRec({ a: 3 })  // succeeds

Objects are compared by comparing the values of their properties via strict equality ===.

Signature:

equalRec([recursionDepth=1], value)

A recursionDepth of 0 means: compare objects with strict equals. A recursionDepth > 0 means: compare the properties of objects via equalRec(recursionDepth-1).

Optional: create a similar analog of eql() called eqlRec()

Leaked Globals

When using expect.js with Mocha and using the throwException assertion, Mocha fails on "leaked globals" for vars message and name. To verify, if I console.log those global vars in my test, they do indeed have values attached to them from throwException for my particular exception's name and message fields.

I'm testing a custom error object, which I've defined as follows (compiled output for CoffeeScript):

(function() {
  var AbstractMethodError,
    __hasProp = {}.hasOwnProperty,
    __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; };

  AbstractMethodError = (function(_super) {

    __extends(AbstractMethodError, _super);

    function AbstractMethodError(message) {
      this.message = message || 'You tried to call an abstract method. You must override this method in your subclass.';
      this.name = 'AbstractMethodError';
    }

    return AbstractMethodError;

  })(Error);

}).call(this);

In looking at the expect.js code for throwException, I'm not sure I understand how the name and message vars are being attached to the global scope. Any thoughts or suggestions?

throwException() improvement

I have a project that does a lot of validations, and if something wrong happens an error is thrown.

If I got a test that asserts an exception being throw and if I accidentally call an undefined method inside the code being tested, the assert passes because it was expected to throw an error. To solve this, we could somehow let users specify the expected type of error (ReferenceError, TypeError, etc). But again, this won't be enough, because one could want to test against the error.code or error.message. This test could be direct or using a regular expression to test for dynamic error messages like 'Method foo() is incomplete ..'.

What you guys think?

Change readme exception example

I would change this:

expect(fn).to.throwException(function (e) { // get the exception object
  expect(e).to.be.a(SyntaxError);
});

to

expect(fn).to.throwException(function (e) { // get the exception object
  expect(e.constructor).to.be(SyntaxError);
});

to ignore inheritance. It surely depends on the test, but I think that you usually want to test for a specific exception, not a "kind of" exception.

Just a suggestion ... :)

[Feature] Custom message

Would it be possible get a facility for adding a custom message to errors? Maybe an extra parameter somewhere, or an extra chained flag:

expect(this).to.be.ok("oh noes");
expect(that).to.be.ok().msg("oh well");

'withArgs' allways runs in global scope

I'm trying to do something like that:

expect(obj.method).withArgs(arg1).to.not.throwException();

And when I do it I expect that obj.method would be calling in obj context (this would be a reference to obj).
But there is a string:

 fn.apply(null, args);

in Assertion.prototype.withArgs. So fn would always called in context of null, which in browser would be replacing with Window object. And I'll always get an global leaks detected error even if there is no actually global leaks.

NPM version is still 0.1.2 but labelled at 0.2.0

The NPM version of expect.js is out of date and mis-labelled. It installs with a package that says it installed 0.2.0, when in fact it's only installed 0.1.2.

Please update the NPM package so that the expect.js source code included is actually 0.2.0. I ask this because it has new methods such as withArgs(), which I'd like to use.

Steps to verify what version was installed: Installing expect.js from npm:
npm install expect.js
open node_modules/expect.js/expect.js

Look for the line expect.version, it shows "0.1.2"

Your isArray implementation and IE6

One of the major selling-points of Expect.js for me, is that it's compatible with older browsers that I need to run my unit tests in.

So, just a heads-up: your implementation of isArray(), used in several places in the codebase, will not work with foreign-context arrays in IE6 and IE7. You should either replace it with a simple instanceof, or if you truly want to support foreign-context arrays (please do, I use these. :), try something else.

(Offending lines: expect.js#746, expect.js#1060)

to.have.length() for non-zero length

I would expect length() to be able to check for any non-zero-length. The cleanest API for this, to me, would be passing no argument:

expect(filled_array).to.have.length()

Also, more powerfully, it'd be nice to be able to chain the numeric operators onto this:

expect(filled_array).to.have.length.greaterThan(2)

throwExecption does not work with Given/When/Then libraries

throwException doesn't return anything, which means any library that bases success/failure on the return value of a test will not work. For instance, I use mocha-given with expect and write tests like this:

Given -> # . . .
When -> # . . .
Then -> expect(@thing.someMethod).to.throwException(/blah/)

Since throwException returns nothing, this amounts to Then -> undefined which fails because it is falsy (even if the method threw as expected). I thought about fixing this myself, but it requires making decisions about how this library should work. In general, none of the expect matchers are great for these kinds of tests because they return this, which DOES pass (most of the time - it's just occurring to me that at least one other weird test case might be the result of this too), but only because it's truthy. Maybe expect could be set up with an option that just returns true/false for pass/fail and otherwise returns this for chaining?

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.