mochajs/mocha

☕️ simple, flexible, fun javascript test framework for node.js & the browser

mocha's Issues

TextMate etc support

switch to stderr

output is getting munged quite a bit since node does not (currently) flush

serve recent .js and .css from site

nicer error reporting for browser tests

"spec" reporter

nesting blah blah

mocha.css

make target

get a domain

duration styling in browser

yellow / red etc

#<WriteStream> has no method 'getWindowSize'

Hank:admin deedubs$ ./node_modules/.bin/mocha

node.js:134
throw e; // process.nextTick error, or 'error' event on first tick
^
TypeError: Object # has no method 'getWindowSize'
at Object. (/Users/deedubs/Projects/admin/node_modules/mocha/lib/reporters/base.js:68:22)
at Module._compile (module.js:411:26)
at Object..js (module.js:417:10)
at Module.load (module.js:343:31)
at Function._load (module.js:302:12)
at require (module.js:355:19)
at Object. (/Users/deedubs/Projects/admin/node_modules/mocha/lib/reporters/index.js:2:16)
at Module._compile (module.js:411:26)
at Object..js (module.js:417:10)
at Module.load (module.js:343:31)
Hank:admin deedubs$ node -v
v0.4.12

ability to target specific tests / suites for execution

this would work into tagging as well

Color duration green/yellow/red accordingly

add thresholds and do this for a few of the reporters so that slow tests stand out

report errors thrown / uncaught / passed in hooks nicely

"some error in setup hook" etc

object diffs

when loose equality is performed it's pretty annoying to see the difference between two arrays, two large objects etc

base other reporters on JSON-Stream

this way we could add a --concurrency <n> flag and aggregate results

add support for pending tests

hook for when all tests are complete

to manually exit the process, kill connections etc

global leak reporting

with whitelist etc

finish browser support

make sure not to use things that I normally do like forEach :D

ensure passing of flags to node(1) is easy

cascade [before/after]Each()

ex:

var app;

describe('config', function(){
  beforeEach(function(){
    app = express();
  })

  describe('.set()', function(){
    it('should set a value', function(){
      app.set('foo', 'bar').should.equal(app);
    })
  })

  describe('.get()', function(){
    it('should get a value', function(){
      //...
    })
  })
})

before/after callbacks

setup / teardown for TDD interface etc

rename tearDown to teardown

bugs me

xunit reporter

jquery for browser support

with no-conflict or whatever

browser report stats

Fix async support

few things breaking, and add more test cov

better growl messages

http://d.pr/nIeW
is not overly useful haha

test cov

write a proper test cov lib

use assert() so browser can run server tests

don't load all reporters when running in the browser

no point, just extra code

expect(n) and matchers

come up with an interface for TDD etc as well

moar padding

for the top of the site

consider supporting a test/mocha.opts file

like spec.opts

node-growl support

styles failures / pending in browser

merge identically named suites

shouldn't have two of the same, this makes it easier to meta-generate tests, nicer reporting etc

Default all to serial / parallel, toggle with flag

add flag(s) to mocha(1), as well as interface functions to toggle the behaviour

test non-tty outputs

Add tagging

like visionmedia/expresso#127 something similar to this, but maybe just file based instead, or maybe we just leave this up to the user to separate them into different files

site

make a website sometime

make sure multiple calls to done() fails

double check test durations

one in express is reporting as 20ms, however when moved below another that one is reported as 20ms haha...

optional parallelism via processes

for cpu-bound tests

mutation cov

html reporter

hook uncaught exception error reporting

map hooks to these

declarative js example

doc reporter

it would be cool to output some html that could be used as reference docs with blocks etc,
retaining the nesting you use in the tests

test for errors/exceptions

The testing for a Method to cause a error would be nice, some methods do raise errors/exceptions (validation for example), and testing for them could help avoid people writing boilerplate to simulate this.

manpage