Test Driven JavaScript Development- P13 ppsx

ptg 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); } From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 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); From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 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 subclassing the Observable class. The motivation for classical inheritance in these cases comes from a desire to define the mechanics of the pattern in one place and reuse the logic across vast amounts of unrelated objects. As discussed in Chapter 7, Objects and Prototypal Inheritance, we have several options for code reuse among JavaScript objects, so we need not confine ourselves to an emulation of the classical inheritance model. Although the Java analogy helped us develop the basic interface, we will now break free from it by refactoring the observable interface to embrace JavaScript’s object model. Assuming we have a Newsletter constructor that creates newsletter objects, there are a number of ways we can make newsletters observ- able, as seen in Listing 11.31. Listing 11.31 Various ways to share observable behavior var Observable = tddjs.util.Observable; // Extending the object with an observable object tddjs.extend(newsletter, new Observable()); // Extending all newsletters with an observable object tddjs.extend(Newsletter.prototype, new Observable()); // Using a helper function tddjs.util.makeObservable(newsletter); // Calling the constructor as a function Observable(newsletter); // Using a "static" method: From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 236 The Observer Pattern Observable.make(newsletter); // Telling the object to "fix itself" (requires code on // the prototype of either Newsletter or Object) newsletter.makeObservable(); // Classical inheritance-like Newspaper.inherit(Observable); In the interest of breaking free of the classical emulation that constructors provide, consider the examples in Listing 11.32, which assume that tddjs. util.observable is an object rather than a constructor. Listing 11.32 Sharing behavior with an observable object // Creating a single observable object var observable = Object.create(tddjs.util.observable); // Extending a single object tddjs.extend(newspaper, tddjs.util.observable); // A constructor that creates observable objects function Newspaper() { /* */ } Newspaper.prototype = Object.create(tddjs.util.observable); // Extending an existing prototype tddjs.extend(Newspaper.prototype, tddjs.util.observable); Simply implementing the observable as a single object offers a great deal of flexibility. To get there we need to refactor the existing solution to get rid of the constructor. 11.6.1 Making the Constructor Obsolete To get rid of the constructor we should first refactor Observable such that the constructor doesn’t do any work. Luckily, the constructor only initializes the observers array, which shouldn’t be too hard to remove. All the methods on Observable.prototype access the array, so we need to make sure they can all handle the case in which it hasn’t been initialized. To test for this we simply need to write one test per method that calls the method in question before doing anything else. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 11.6 Observing Arbitrary Objects 237 As seen in Listing 11.33, we already have tests that call addObserver and hasObserver before doing anything else. Listing 11.33 Tests targeting addObserver and hasObserver TestCase("ObservableAddObserverTest", { "test should store functions": function () { var observable = new tddjs.util.Observable(); var observers = [function () {}, function () {}]; observable.addObserver(observers[0]); observable.addObserver(observers[1]); assertTrue(observable.hasObserver(observers[0])); assertTrue(observable.hasObserver(observers[1])); }, /* */ }); TestCase("ObservableHasObserverTest", { "test should return false when no observers": function () { var observable = new tddjs.util.Observable(); assertFalse(observable.hasObserver(function () {})); } }); The notifyObservers method however,is only tested after addObserver has been called. Listing 11.34 adds a test that expects it to be possible to call this method before adding any observers. Listing 11.34 Expecting notifyObservers to not fail if called before addObserver "test should not fail if no observers": function () { var observable = new tddjs.util.Observable(); assertNoException(function () { observable.notifyObservers(); }); } With this test in place, we can empty the constructor as seen in Listing 11.35. From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 238 The Observer Pattern Listing 11.35 Emptying the constructor function Observable() { } Running the tests shows that all but one is now failing, all with the same message: “this.observers is not defined.” We will deal with one method at a time. Listing 11.36 shows the updated addObserver method. Listing 11.36 Defining the array if it does not exist in addObserver function addObserver(observer) { if (!this.observers) { this.observers = []; } /* */ } Running the tests again reveals that the updated addObserver method fixes all but the two tests that do not call it before calling other methods, such as hasObserver and notifyObservers. Next up, Listing 11.37 makes sure to return false directly from hasObserver if the array does not exist. Listing 11.37 Aborting hasObserver when there are no observers function hasObserver(observer) { if (!this.observers) { return false; } /* */ } We can apply the exact same fix to notifyObservers, as seen in Listing 11.38. Listing 11.38 Aborting notifyObservers when there are no observers function notifyObservers(observer) { if (!this.observers) { return; } /* */ } From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 11.6 Observing Arbitrary Objects 239 11.6.2 Replacing the Constructor with an Object Now that the constructor doesn’t do anything, it can be safely removed. We will then add all the methods directly to the tddjs.util.observable object, which can then be used with, e.g., Object.create or tddjs.extend to create observable objects. Note that the name is no longer capitalized as it is no longer a constructor. Listing 11.39 shows the updated implementation. Listing 11.39 The observable object (function () { function addObserver(observer) { /* */ } function hasObserver(observer) { /* */ } function notifyObservers() { /* */ } tddjs.namespace("util").observable = { addObserver: addObserver, hasObserver: hasObserver, notifyObservers: notifyObservers }; }()); Surely, removing the constructor will cause all the tests so far to break. Fixing them is easy, however; all we need to do is to replace the new statement with a call to Object.create, as seen in Listing 11.40. Listing 11.40 Using the observable object in tests TestCase("ObservableAddObserverTest", { setUp: function () { this.observable = Object.create(tddjs.util.observable); }, /* */ }); TestCase("ObservableHasObserverTest", { setUp: function () { From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 240 The Observer Pattern this.observable = Object.create(tddjs.util.observable); }, /* */ }); TestCase("ObservableNotifyObserversTest", { setUp: function () { this.observable = Object.create(tddjs.util.observable); }, /* */ }); To avoid duplicating the Object.create call, each test case gained a setUp method that sets up the observable for testing. The test methods have to be updated accordingly, replacing observable with this.observable. For the tests to run smoothly on any browser, the Object.create imple- mentation from Chapter 7, Objects and Prototypal Inheritance, needs to be saved in lib/object.js. 11.6.3 Renaming Methods While we are in the game of changing things we will take a moment to reduce the ver- bosity of the interface by renaming the addObserver and notifyObservers methods. We can shorten them down without sacrificing any clarity. Renaming the methods is a simple case of search-replace so we won’t dwell on it too long. Listing 11.41 shows the updated interface, I’ll trust you to update the test case accordingly. Listing 11.41 The refurbished observable interface (function () { function observe(observer) { /* */ } /* */ function notify() { /* */ } tddjs.namespace("util").observable = { From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 11.7 Observing Arbitrary Events 241 observe: observe, hasObserver: hasObserver, notify: notify }; }()); 11.7 Observing Arbitrary Events The current observable implementation is a little limited in that it only keeps a single list of observers. This means that in order to observe more than one event, observers have to determine what event occurred based on heuristics on the data they receive. We will refactor the observable to group observers by event names. Event names are arbitrary strings that the observable may use at its own discretion. 11.7.1 Supporting Events in observe To support events, the observe method now needs to accept a string argument in addition to the function argument. The new observe will take the event as its first argument. As we already have several tests calling the observe method, we can start by updating the test case. Add a string as first argument to any call to observe as seen in Listing 11.42. Listing 11.42 Updating calls to observe TestCase("ObservableAddObserverTest", { /* */ "test should store functions": function () { /* */ this.observable.observe("event", observers[0]); this.observable.observe("event", observers[1]); /* */ }, /* * }); TestCase("ObservableNotifyObserversTest", { /* */ "test should call all observers": function () { From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 242 The Observer Pattern /* */ this.observable.observe("event", observer1); this.observable.observe("event", observer2); /* */ }, "test should pass through arguments": function () { /* */ this.observable.observe("event", function () { actual = arguments; }); /* */ }, "test should notify all even when some fail": function () { /* */ this.observable.observe("event", observer1); this.observable.observe("event", observer2); /* */ }, "test should call observers in the order they were added": function () { /* */ this.observable.observe("event", observer1); this.observable.observe("event", observer2); /* */ }, /* */ }); Unsurprisingly, this causes all the tests to fail as observe throws an exception, because the argument it thinks is the observer is not a function. To get tests back to green we simply add a formal parameter to observe, as seen in Listing 11.43. Listing 11.43 Adding a formal event parameter to observe function observe(event, observer) { /* */ } We will repeat this exercise with both hasObserver and notify as well, to make room for tests that describe actual functionality. I will leave updating these From the Library of WoweBook.Com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... shows the test in full; save it in test/ ajax _test. js Listing 12.3 Testing for an XMLHttpRequest object TestCase("AjaxCreateTest", { "test should return XMLHttpRequest object": function () { var xhr = tddjs.ajax.create(); assertNumber(xhr.readyState); assert(tddjs.isHostMethod(xhr, "open")); assert(tddjs.isHostMethod(xhr, "send")); assert(tddjs.isHostMethod(xhr, "setRequestHeader")); } }); This test fails... | ' request.js ` test ' ajax _test. js ' request _test. js Listing 12.2 The jsTestDriver.conf file server: http://localhost:4224 load: - lib/*.js - src/*.js - test/ *.js Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark From the Library of WoweBook.Com 250 Abstracting Browser Differences: Ajax The tdd.js file should contain the utilities built in Part II, JavaScript for Programmers... We will not make any server side requests from within the unit tests themselves, because doing so will make the tests harder to run (we’ll need someone answering those requests) and it makes it harder to test isolated behavior Unit tests are there to drive us through development of the higher level API They are going to help us develop and test the logic we build on top of the native transport, not the... chapter Remember that our main focus is to learn test- driven development, meaning that we should concentrate on the thought process and how tests form requirements Additionally, we will keep practicing continuous refactoring to improve the implementation, API, and tests Stubbing is a powerful technique that allows true isolation of the system under test Stubs (and mocks) have not been discussed in... 11.7 Observing Arbitrary Events other two functions (and their tests) as an exercise When you are done you will note that one of the tests keep failing We will deal with that last test together 11.7.2 Supporting Events in notify While updating notify to accept an event whose observers to notify, one of the existing tests stays in the red The test in question is the one that compares arguments sent to... and paving the road with tests will allow us to go just as far as we need, providing a solid base for future extension 12.1 Test Driving a Request API Before we get started, we need to plan how we will be using test- driven development to abstract browser inconsistencies TDD can help discover inconsistencies to some degree, but the nature of some bugs are so obscure that unit tests are unlikely to discover... Because unit tests are unlikely to accidentally discover all kinds of browser bugs, some amount of exploration is necessary to uncover the bugs we’re abstracting However, unit tests can help us make sure we cover the holes by triggering offending behavior from within tests and making sure that production code copes with these situations Incidentally, this is the same way we usually use unit tests to “capture”... gained a good understanding of the important role of refactoring in test- driven development It is through refactoring, both in production code and tests, that our solutions can grow refined and elegant In the next chapter we will deal more closely with browser inconsistencies as we dig into the mechanics of “Ajax”, using test- driven development to implement a higher level interface on top of the XMLHttpRequest... not the logic a given browser vendor built into their XMLHttpRequest implementation Testing our own logic is all fine and dandy, but we still need to test that the implementation really works when sitting on top of an actual XMLHttpRequest object To do this, we will write an integration test once the API is usable This test will be the real deal; it will use our interface to make requests to the server... that it either works or fails gracefully 12.1.3 The Goal The decision to write an XMLHttpRequest wrapper without actually using it inside the tests may sound strange at first, but allow me to remind you yet again of the goal of test- driven development; TDD uses tests as a design tool whose main purpose is to guide us through development In order to truly focus on units in isolation, we need to eliminate . headers. Listing 12.3 shows the test in full; save it in test/ ajax _ test. js. Listing 12.3 Testing for an XMLHttpRequest object TestCase("AjaxCreateTest", { " ;test should return XMLHttpRequest. object in tests TestCase("ObservableAddObserverTest", { setUp: function () { this.observable = Object.create(tddjs.util.observable); }, /* */ }); TestCase("ObservableHasObserverTest",. ajax.js | ' request.js ` test ' ajax _test. js ' request _test. js Listing 12.2 The jsTestDriver.conf file server: http://localhost:4224 load: - lib/*.js - src/*.js - test/ *.js From the Library