This was a good answer. I took a swing at mocking out XMLHTTPRequest in the patch attached to SHINDIG-338.
On Sat, Jun 14, 2008 at 8:03 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Sat, Jun 14, 2008 at 7:00 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > >> I'm writing unit tests for io.js, because I'm about to change it and >> changing code without unit tests makes me nervous. Some of the >> internal functions are difficult to test because they are hidden in a >> closure. I like hiding implementation details in a closure, but I >> like testing more. I'm thinking about modifying the code so the style >> is more in the style of js classes, such as person.js. >> >> As an example of the kind of function that is giving me trouble, >> consider processResponse. It's had bugs in the past, it will in the >> future, but the interface is clean enough that it *should* be >> testable. I can't figure out how to test it without pulling it out of >> the closure. >> >> Are there better alternatives? > > > Test the public interfaces. For gadgets.io, you just need to mock out > window.XmlHttpRequest and you're good to go. If you've written what you > think are adequate tests for all the public interfaces, but there is > internal code that hasn't been properly exercised, this tells you one of two > things: > > 1. You have useless code internally. Eliminate it. > 2. Your tests aren't thorough enough. > > Consider what's important here. Does it matter if processResponse (and > unimportant implementation detail) changes, or that makeRequest handles all > calls correctly? Thorough tests on makeRequest (and the other public > methods) will guarantee that the code does the right thing regardless of > what changes internally. That's really the core of good testing practice in > the first place -- you want to make sure that your code does what it's > supposed to do, regardless of what you change internally. > > What happens if I go through and rewrite large parts of gadgets.io and > completely eliminate the call to processResponse tomorrow? I may have > introduced new bugs in makeRequest without knowing it. I've violated the > public contract, but the tests continue to pass. That's wrong, and the > source of most regression bugs in large code bases. > > To take this further, look a closely related piece of code -- the > server-side ProxyHandler. If all we did was test at the HttpFetcher level, > subsequent replacements of HttpFetcher with a completely different mechanism > for content retrieval could be completely wrong, and we'd never know it > because we didn't actually test that ProxyHandler did what it claimed to do. > We could have as thorough tests as possible around HttpFetcher (and we > should, because it is also a public interface), but that would mean jack > squat if we didn't thoroughly test what ProxyHandler was doing, because > HttpFetcher might simply change in the future and no longer do this thing > that we were counting on. > > >> >> Cheers, >> Brian >> >
