The module should be the primary unit of functionality. If you are finding that you need to unit-test functions inside a module, then chances are your module is too big, or private functions should be public, or built-in behavior should be configurable.
On Sat, Jun 30, 2012 at 3:15 PM, Saleem Abdul Hamid <[email protected]> wrote: > 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 [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 > > -- > 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 -- 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
