如何防止文件在Node.js中完成以按顺序运行测试？

Question

I've got tape.js tests in different files that alter my database.

They work fine when run individually, but when running all the files like this tape tests/**/*.js the tests fail - because tests in the second file start running before the first file has finished and the database state is incorrect.

How do I prevent Node from exiting a file while waiting for an async call to finish?

Neither of these ideas I had will work:

function wait()  //blocks forever so the test can never finish
{
   while (!testsFinished) {;} 
}

function wait()  //returns immediately because it uses a timeout
{
   if (!testsFinished)
      setTimeout(wait, 1000);
}

The only other option I can think of is to write my own test file manager that uses async.series([....]) to call each file individually. But that would be reinventing the wheel - writing my own test runner framework.

Answer 1

Seems like you need blue-tape in your control flow, by adding promises you can join the two tests into a single one, then turn each test result into a promise and chain both promises.

test("simple test", function(t) {
    return test1();
});

test("nested test", function(t) {
    return test1().then(function() {
         return test2();
    });
});

you might take a look to bluebird if you want to pomisify tape as well.

I hope that helps, otherwise you can use another (more robust) testing framework like mocha

Answer 2

Even if I used promises as jack.the.ripper suggests I think the files would still exit, or I'd have to write one central test file manager that calls other files, as his code shows.

Instead I think the only solution is to call each test individually in my script, swapping this:

tape 'server/tests/integration/**/*.js' | faucet

for this:

tape 'server/tests/integration/webservice/routes/signUpRouteTest.js' | faucet
tape 'server/tests/integration/webservice/routes/authenticateEmailConfirmRouteTest.js' | faucet
tape 'server/tests/integration/webservice/routes/authenticateEmailRejecRouteTest.js' | faucet

Since nodejs won't exit while an async call is pending each test will run only after the previous has finished. And having one line per test file in my script I guess is not the end of the world...

Answer 3

This is probably not advised, but theoretically you could add properties onto nodes global object.

test1.js

var test = require( 'tape' ) ;
var util = require('util');

test( 'My first test file', function( assert ) {
  assert.equal( 1, 1, 'Numbers 1 and 1 are the same' ) ;
  assert.equal( 2, 2, 'Numbers 2 and 2 are the same' ) ;
  assert.equal( 3, 3, 'Numbers 3 and 3 are the same' ) ;


  myglobalvariableWithoutVarKeyword = 'shared var';
  console.log('test1 shared var= ' + util.inspect(myglobalvariableWithoutVarKeyword));  

  assert.end() ;
} ) ;

test2.js

var test = require( 'tape' ) ;
var util = require('util');

test( 'My second test file', function( assert ) {
  assert.equal( 4, 4, 'Numbers 4 and 4 are the same' ) ;
  assert.equal( 5, 5, 'Numbers 5 and 5 are the same' ) ;
  assert.equal( 6, 6, 'Numbers 6 and 6 are the same' ) ;


  console.log('test2 shared var= ' + util.inspect(myglobalvariableWithoutVarKeyword));  
  assert.end() ;
} ) ;

Outputs:

 My first test file

    √ Numbers 1 and 1 are the same
    √ Numbers 2 and 2 are the same
    √ Numbers 3 and 3 are the same
    test1 shared var = 'shared var';

  My second test file

    √ Numbers 1 and 1 are the same
    √ Numbers 2 and 2 are the same
    √ Numbers 3 and 3 are the same
    test2 shared var = 'shared var';

With this approach you could test if the shared variable has loaded all the tests, and then run assert.end() using promises.

Answer 4

Frankly, your unit tests shouldn't alter your database. If you want to do it right, you should completely isolate your db from the unit tests.

Besides that: Your unit tests should be able to run at any time in any order without influencing each other. If this isn't the case, you don't have good unit tests.

You can go the easy way and try to run the tests in order or you can do it properly, invest some time and get rid of the database dependency. Only the second solution is desirable.