There are situations where that is simply not enough. For example, let's say you have a working module but you want to add an optimization like caching to it. With or without caching the exposed interface will work exactly the same (as it should). So there's really not another way to test except to access some private functions or variables while testing.
I found this nice solution: http://howtonode.org/testing-private-state-and-mocking-deps which doesn't require you to modify the code being tested for it to work. You could also test both an exposed and regular version of your module in the same file, so in tests where it is not really necessary to know about private state, you would be testing the api more realistically as Joe mentioned. On Monday, May 7, 2012 1:14:54 PM UTC-7, JoeZ99 wrote: > > In my personal point of view, the whole point of modulus programming is > that you only want to expose certain functions and the other "private > functions" are for "internal use" only. so, when testing, that is to be > tested too, the behavior of the module exposing only a part of its api. > > Personally I think is better to mock all the possible inputs and outputs > to the module and test it, a little more work is needed, but tests are more > trustworthy. > > On Monday, May 7, 2012 12:14:51 PM UTC-4, Jeff Barczewski wrote: >> >> Martin, >> >> Sidedoor seems like an elegant solution. I will give this a try. >> >> Thanks, >> >> Jeff >> >> On Sunday, 6 May 2012 10:27:51 UTC-5, Martin Cooper wrote: >>> >>> On Thu, May 3, 2012 at 8:04 PM, P. Douglas Reeder wrote: >>> > Writing functional tests for the functions exposed by a module is >>> > straightforward, using any of the many TDD framework for Node. >>> > >>> > However, it's not clear what the best approach is, to writing unit >>> > tests for functions that are not exposed by a module. >>> > >>> > One possibility is to write unit tests as part of the module and >>> > expose one or more test methods. However, it's not clear how unit >>> > tests could then be excluded from a production module. >>> > >>> > What is the usual approach? is it possible to write a test submodule >>> > and cleanly exclude it from a production module? >>> >>> This is exactly why I wrote Sidedoor: >>> >>> https://github.com/mfncooper/sidedoor >>> >>> It lets you expose secondary APIs from your module that don't pollute >>> the regular 'exports' API. >>> >>> Your tests know that they need to access the functions exposed via the >>> "side door", so they use the Sidedoor API to get at those functions. >>> Your main module can choose to always expose the secondary API (safe >>> in the knowledge that someone looking at 'exports' won't see it), or >>> choose to conditionally expose it, if you want it to just not be there >>> outside of tests. >>> >>> -- >>> Martin Cooper >>> >>> >>> > -- >>> > 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 nodejs@googlegroups.com >>> > To unsubscribe from this group, send email to >>> > nodejs+unsubscr...@googlegroups.com >>> > For more options, visit this group at >>> > http://groups.google.com/group/nodejs?hl=en?hl=en >>> >> -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
