Test Driven JavaScript Development- P13

Test Driven JavaScript Development- P13:This book is about programming JavaScript for the real world, using the techniquesand workflow suggested by Test-Driven Development. It is about gaining confidencein your code through test coverage, and gaining the ability to fearlessly refactor andorganically evolve your code base. It is about writing modular and testable code. Itis about writing JavaScript that works in a wide variety of environments and thatdoesn’t get in your user’s way.
Nội dung trích xuất từ tài liệu:
Test Driven JavaScript Development- P13 11.5 Error Handling 233 By throwing an exception already when adding the observers we don’t need to worry about invalid data later when we notify observers. Had we been pro- gramming by contract, we could say that a precondition for the addObserver method is that the input must be callable. The postcondition is that the observer is added to the observable and is guaranteed to be called once the observable calls notifyObservers. The test fails, so we shift our focus to getting the bar green again as quickly as possible. Unfortunately, there is no way to fake the implementation this time— throwing an exception on any call to addObserver will fail all the other tests. Luckily, the implementation is fairly trivial, as seen in Listing 11.27. Listing 11.27 Throwing an exception when adding non-callable observers function addObserver(observer) { if (typeof observer != function) { throw new TypeError(observer is not function); } this.observers.push(observer); } addObserver now checks that the observer is in fact a function before adding it to the list. Running the tests yields that sweet feeling of success: All green. 11.5.2 Misbehaving Observers The observable now guarantees that any observer added through addObserver is callable. Still, notifyObservers may still fail horribly if an observer throws an exception. Listing 11.28 shows a test that expects all the observers to be called even if one of them throws an exception. Listing 11.28 Expecting notifyObservers to survive misbehaving observers test should notify all even when some fail: function () { var observable = new tddjs.util.Observable(); var observer1 = function () { throw new Error(Oops); }; var observer2 = function () { observer2.called = true; }; observable.addObserver(observer1); observable.addObserver(observer2); observable.notifyObservers(); assertTrue(observer2.called); }Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 234 The Observer Pattern Running the test reveals that the current implementation blows up along with the first observer, causing the second observer not to be called. In effect, noti- fyObservers is breaking its guarantee that it will always call all observers once they have been successfully added. To rectify the situation, the method needs to be prepared for the worst, as seen in Listing 11.29. Listing 11.29 Catching exceptions for misbehaving observers function notifyObservers() { for (var i = 0, l = this.observers.length; i < l; i++) { try { this.observers[i].apply(this, arguments); } catch (e) {} } } The exception is silently discarded. It is the observers responsibility to ensure that any errors are handled properly, the observable is simply fending off badly behaving observers. 11.5.3 Documenting Call Order We have improved the robustness of the Observable module by giving it proper error handling. The module is now able to give guarantees of operation as long as it gets good input and it is able to recover should an observer fail to meet its require- ments. However, the last test we added makes an assumption on undocumented features of the observable: It assumes that observers are called in the order they were added. Currently, this solution works because we used an array to implement the observers list. Should we decide to change this, however, our tests may break. So we need to decide: Do we refactor the test to not assume call order, or do we simply add a test that expects call order, thereby documenting call order as a fea- ture? Call order seems like a sensible feature, so Listing 11.30 adds the test to make sure Observable keeps this behavior. Listing 11.30 Documenting call order as a feature test should call observers in the order they were added: function () { var observable = new tddjs.util.Observable(); var calls = []; var observer1 = function () { calls.push(observer1); }; var observer2 = function () { calls.push(observer2); }; observable.addObserver(observer1);Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 11.6 Observing Arbitrary Objects 235 observable.addObserver(observer2); observable.notifyObservers(); assertEquals(observer1, calls[0]); assertEquals(observer2, calls[1]); } Because the implementation already uses an array for the observers, this test succeeds immediately. 11.6 Observing Arbitrary Objects In static languages with classical inheritance, arbitrary objects are made observable by subclassin ...