i thought about suggesting it, but i decided not to do it. test are insurance tools, that the cases you've thought about are working and do not contain bugs. but tests are software too and may have bugs in it. so thats why my testing tools and strategy have to be as simple as it could, so i can better assure, that my test infrastructure is safe, or at least much more safer than the application i test with it. so to dig into deep of nodes Module system (this is where the require magic happens), to rewrite it and then hope that no other 1st, 2nd or 3rd party lib we use will silently break is not a real solution. as is said, better solution is to design your code for testability, where you nearly never have to mock something. every time you're mocking the 3rd party tool, you're creating an api specification and prove that the lib conforms to it. this is already hard with isolated modules like user-land libs, it's even harder with platforms essential modules as Module.
Am Dienstag, 22. Januar 2013 06:22:56 UTC+1 schrieb nin jin: > > You can implement custom "require". This is easy) > http://nodejs.org/api/vm.html > > воскресенье, 20 января 2013 г., 8:15:13 UTC+4 пользователь Athan Clark > написал: >> >> Hello everyone. I'd like to make unit testing a practice difficult to >> evade in Node.js. One of the requirements, though, is that you need to be >> able to test a module's functionality independently of it's dependencies >> (say that 10 times fast!). My idea is to make node more flexible in the >> directories it chooses to look for node modules by providing an alternative >> "mode" for it to look in - ie if *NODE_MODE* is set to "test", then npm >> will first try to look in ./test_node_modules for a package before looking >> in ./node_modules. That way we can provide *alternative *modules for a >> package - ie mock ones. Or if you were trying to make a package that was >> compatible with similar modules, you could have a 3rd party testing >> package, like a simple blog, that uses the similar package in one mode, >> then your package in another. >> >> Imagine being able to do a *`npm run-scripts test --deep`*, and then see >> each and every module complete a unit test before progressively walking up >> the dependance tree making scenario tests along the way. It makes my >> continuous integration senses salivate. >> >> What do you all think? Could someone could direct me to where/how npm / >> node implements `require();`? Where should I start? >> >> Thanks in advance!! >> > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
