Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Possiblity of SandBoxed Tests #592

Closed
devdazed opened this Issue · 6 comments

3 participants

@devdazed

Would it be possible to implement a flag like --sandboxed that will run each test suite in it's own VM. A feature like this would really make mocking easier, even possible in some cases.

@tj
Owner
tj commented

-1 from me for a few reasons, mainly being that mocha currently loads everything all at once and this would cause a bit gap in the server / client-side implementation, secondly I can't think of anything that is unmock-able without this feature, what's an example? I'm not a huge proponent of mocking in general but this would be a large overhaul if it's mostly for convenience

@devdazed

I guess, it isn't only for mocking (just fo my direct use case it is). Although it isn't in best practice to do something like this, for brevity and simplicity sake here is an example, also, maybe a VM is not exactly what I'm looking for here.

app.js

var express = require('express');
var app = express();

app.request_count = 0;

app.get('/', function(req, res){
  res.send('Count = ' + app.request_count);
});

module.exports = app;

something_that_requires_app.js

var app = require('./app');
//do stuff with app

app_test.js

suite('test_app', function(){
  test('should count', function(done){
    var app = require('./app');
    app.listen();
    // ...make some requests
    assert.ok(app.request_count == 3);
  });
});

suite('test_runner', function(){
  test('foo', function(){
    //some tests on runner that will ultimately fail because the 
    //app variable will only be set on the first require
  });
});

anyways, I think you get the idea here. Since certain variables are set when the module first loads, they won't get set again. As it pertains to mocking, when something requires say a driver in one test and that driver is mocked, in the next test, if you don't do the work to clear the requires cache etc to reload the module from scratch it will be the same mock when you may want a different mock.

My idea is that if each suite is ran in its own context you can easier control the module loads. Or maybe I'm over thinking it, maybe what I really want is a function to reload modules on each suite load, or test.

@tj
Owner
tj commented

my opinion with that sort of thing is also largely that if it's difficult to test, it's the wrong abstraction. Global singletons that cannot be reset etc, anything that doesn't lend itself to relatively simple testing or isolation is usually a bad abstraction

@wilmoore

+1 to the -1

@devdazed

I agree that it is a bad abstraction, and as well, a practice that I would never use. The main reason that I want it is to be able to set and unset mocks at the require level.

I also believe that a test suite should lend itself to work with however a developer wants to write their application. I would be against this if it changed the way the testing suite worked, but as a feature invoked by a flag, it would be very helpful.

@wilmoore

@visionmedia This issue seems like it can be closed at this point.

In Summary:

  • Test framework should not be responsible for fixing code that isn't correctly built for isolation (no offense intended).
  • There are other frameworks that try to pull this off, but it just causes more problems than it solves.
@tj tj closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.