2011-03-05 18 views
6

Digamos que hice uso de la siguiente patrón módulo de clase en JavaScript:de prueba Unidad clases particulares

var myModule = (function() { 
    var Foo = function() { /* ... */ }; 
    var Bar = function() { 
     this.foo = new Foo(); 
    }; 
    Bar.prototype.someMethod = function() { 
     this.foo.someMethod(); 
    }; 
    return { 
     'Bar': Bar 
    }; 
})(); 

¿Es conveniente y si es así - ¿cómo puedo exponer Foo para las pruebas unitarias? ¿Hay alguna técnica o patrón común para hacer esto?

Respuesta

6

No creo que realmente deba probar los miembros private de la unidad. Siempre que tenga pruebas exhaustivas de los miembros públicos, cualquier error dentro de los miembros privados se manifestará como errores en los miembros públicos. A continuación, puede utilizar la buena depuración para descubrir cuál fue el problema exacto.

Alternativamente, si tiene sus pruebas se ejecutan en una compilación separada a la producción, puede exponer el objeto adjunto y probar en contra de eso. Debería recordar eliminar la referencia al objeto adjunto antes de la implementación, o podría automatizarlo de alguna manera. Honestamente, en general, no me molestaría en eliminarlo, a menos que esté empacando una biblioteca para el consumo público.

var myModule = (function() { 
    var _this = this; 
    var Foo = function() { /* ... */ }; 
    var Bar = function() { 
     this.foo = new Foo(); 
    }; 
    Bar.prototype.someMethod = function() { 
     this.foo.someMethod(); 
    }; 
    return { 
     'Bar': Bar, 
     '__private__': _this 
    }; 
})(); 

function test_foo(obj) { 
    var foo = obj.__private__.Foo; 
    assert(foo.prop, 10) 
} 

Para un sistema en las instalaciones, pudiendo acceder a los datos/eventos privados es generalmente no sea un problema, si se entiende claramente que el acceso miembros privados no se debe hacer. Esto se resalta al proporcionar una referencia al objeto adjunto con un nombre como __private__. (¿Puedes decir que estoy un poco en Python?;))