Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

convert tests to mocha #849

Merged
merged 9 commits into from
Jul 20, 2015
Merged

convert tests to mocha #849

merged 9 commits into from
Jul 20, 2015

Conversation

charlierudolph
Copy link
Contributor

@aearly @megawac

just a proof of concept where you can run mocha tests in node and in the browser.
Works right along side the nodeunit tests, so could be transitioned over one by one.

@aearly
Copy link
Collaborator

aearly commented Jul 17, 2015

It's beautiful. 😂

@@ -0,0 +1,44 @@
var async = require('../lib/async');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a big fan of the suffixed file names. Why not just run tests on everything in mocha_test/*

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats what happening at the moment anyway. Would you want this named forever.js?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, file name = function name?

On Fri, Jul 17, 2015 at 7:03 PM, Charlie Rudolph notifications@github.com
wrote:

In mocha_test/forever_test.js
#849 (comment):

@@ -0,0 +1,44 @@
+var async = require('../lib/async');

Thats what happening at the moment anyway. Would you want this named
forever.js?


Reply to this email directly or view it on GitHub
https://github.com/caolan/async/pull/849/files#r34938385.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats what happening at the moment anyway

No, karma looks only for _test

@megawac
Copy link
Collaborator

megawac commented Jul 17, 2015

You have to set this in travis.yml

addons:
  firefox: "39.0"

@megawac
Copy link
Collaborator

megawac commented Jul 17, 2015

This will make it difficult to support index.html without a conversion script.The way we do this in marionette is we expose the mocha & chai stuff globally in a setup script

@charlierudolph
Copy link
Contributor Author

What is the requirement to support index.html?

@aearly
Copy link
Collaborator

aearly commented Jul 17, 2015

Can karma run nodeunit?

@aearly
Copy link
Collaborator

aearly commented Jul 17, 2015

Anyway, I say we merge this, and then start improving on it. 👍

@charlierudolph
Copy link
Contributor Author

Yes it does appear karma can run nodeunit. Unsure if it can mocha and nodeunit at the same time though

@charlierudolph
Copy link
Contributor Author

Added karma-mocha-reporter so we get nice output when karma runs tests.

@megawac
Copy link
Collaborator

megawac commented Jul 17, 2015

What is the requirement to support index.html?

I don't know I think its nice to be able run with index.html, mainly for people without node/npm installed/windows that can't install some modules

@megawac
Copy link
Collaborator

megawac commented Jul 17, 2015

Yes it does appear karma can run nodeunit. Unsure if it can mocha and nodeunit at the same time though

Would require 2 karma config files

@charlierudolph
Copy link
Contributor Author

Got karma with nodeunit running

> karma start karma.nodeunit.js 
17 07 2015 17:50:04.020:INFO [framework.browserify]: 166580 bytes written (1.03 seconds)
17 07 2015 17:50:04.026:INFO [framework.browserify]: bundle built
17 07 2015 17:50:04.037:WARN [karma]: Port 9876 in use
17 07 2015 17:50:04.038:INFO [karma]: Karma v0.13.2 server started at http://localhost:9877/
17 07 2015 17:50:04.079:INFO [launcher]: Starting browser Firefox
17 07 2015 17:50:06.474:INFO [Firefox 39.0.0 (Mac OS X 10.10.0)]: Connected on socket LoIOgPA7NY7eHwTYAAAA with id 48556242
Firefox 39.0.0 (Mac OS X 10.10.0)  parallel limit object FAILED
    same
    AssertionError: [1,3,2] deepEqual [1,2,3]
Firefox 39.0.0 (Mac OS X 10.10.0): Executed 231 of 148 (1 FAILED) (23.839 secs / 22.632 secs)
> 

Looks like a few bugs. We can add this in a separate PR if we want it

aearly added a commit that referenced this pull request Jul 20, 2015
@aearly aearly merged commit 2dae787 into caolan:master Jul 20, 2015
@aearly
Copy link
Collaborator

aearly commented Jul 20, 2015

Ok, we can start migrating this as we see fit. Also, karma makes node_modules huge...

@charlierudolph charlierudolph deleted the cr-splitTests branch July 20, 2015 15:47
@megawac
Copy link
Collaborator

megawac commented Jul 22, 2015

I'm having second thoughts on this. I'm not sure if mocha is the right choice for the testRunner.

I would prefer a test runner that allows users to run tests in parallel. Currently the test suite takes about 10-20 seconds (unmeasured) to execute. It'd be sweet if we could use a test runner that allows us to run these tests at the same time.

Mocha doesn't give us this mochajs/mocha#98; I think tape, jest, or lab. I see caolan explicitly decided against parallel tests in node-unit

@charlierudolph
Copy link
Contributor Author

I don't see much benefit from running the tests in parallel. Each test fakes async operations with setTimeout with low to no delay. There are no long running async operations.

@megawac
Copy link
Collaborator

megawac commented Jul 22, 2015

Minimal delay (its about 20+ ms depending on the test) adds up across hundreds of tests. This is clearly illustrated as we are currently past a 21 second running time.

A lot of this time is spent in the I/O event timer call stack, which could be minimized through parallelization


The 5 mocha tests you've converted thus far take 200ms!

@charlierudolph
Copy link
Contributor Author

1 of those is 174 ms spent making sure forever can avoid a stack overflow.

@megawac
Copy link
Collaborator

megawac commented Jul 22, 2015

1 of those is 174 ms spent making sure forever can avoid a stack overflow.

Yes, and the majority of that time is spent waiting for recursive setImmediates to resolve

@aearly
Copy link
Collaborator

aearly commented Jul 22, 2015

Ha, I tried making parallel mocha work a while back: mochajs/mocha#849

The problem is if you have tests running in parallel and an exception is thrown, the process.on("uncaughtError") handler won't know which test failed. Domains were insufficient. You really need multiple processes to get effective parallelism in mocha. Any test runner will have the same issue.

@megawac
Copy link
Collaborator

megawac commented Jul 23, 2015

Par chance, have you looked into how jest goes about it @aearly

@aearly
Copy link
Collaborator

aearly commented Jul 23, 2015

At a quick glance, it looks like they use a multi-process test runner.

@megawac
Copy link
Collaborator

megawac commented Mar 16, 2016

Upon further review, I think https://github.com/sindresorhus/ava would be the best test runner for this project

@aearly
Copy link
Collaborator

aearly commented Mar 21, 2016

Ugh, always new tools. I'd be hesitant to switch to it, seeing as we're not even halfway through migrating to mocha. Mocha is also has really good adoption in the greater JS world, so it's one less thing for a new contributor to learn most of the time.

@megawac
Copy link
Collaborator

megawac commented Mar 22, 2016

Sure it's relatively new, however, that library aims to solve the main
issues I have with node unit. Whereas mocha doesnt have much advantage
outside of plugin support.

The nice thing about Ava is it uses tap api so if we run into issues we
could just use tape or prova. Tap is also easier to find replace for node
unit to tap over node unit to expect
On Mar 21, 2016 4:29 PM, "Alex Early" notifications@github.com wrote:

Ugh, always new tools. I'd be hesitant to switch to it, seeing as we're
not even halfway through migrating to mocha. Mocha is also has really good
adoption in the greater JS world, so it's one less thing for a new
contributor to learn most of the time.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#849 (comment)

@aearly
Copy link
Collaborator

aearly commented Mar 22, 2016

Another thing, I just noticed Ava doesn't support browsers -- only jsdom.

@megawac
Copy link
Collaborator

megawac commented May 5, 2016

Another thing, I just noticed Ava doesn't support browsers -- only jsdom.

Yes, but it runs on the tape protocol which works in the browser

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants