I do not think you really need unit test of private members. If you have exhaustive tests for public members, any errors within private members will appear as errors for public users. Then you can use some good debugging information to find out exactly what the problem is.
Alternatively, if you conduct tests on a separate assembly for production, you can open a closed object and test it. You did not need to delete the link to the surrounding object before deployment - or you can somehow automate it. Honestly, I would not delete it at all if you did not pack the library for public consumption.
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) }
For an internal system, access to private data / functions is usually not a problem if it is understood that access to private members should not be performed. This is emphasized by providing a reference to an object object of type __private__ . (Can you say that I am in Python?))
Josh Smeaton
source share