DESIGN FOR EASIER TESTING in Font

Creation Code39 in Font DESIGN FOR EASIER TESTING

Figure 10 7. A Flex UI matching the Quote Hotel Price use case. Compare with the guessed-at UI from 9. Another problem with the Flex code from 9 was that the form validation logic was closely tied into the UI markup. There was little or no OO encapsulation going on. To fix this, we could create a PriceSearch class and give it properties matching the form. Here s the beginning of such a class, before any behavior is added: public class PriceSearch { private var numNights: int; private var hotelID: String; } But if you check the screenshot in Figure 10 7, it s obvious that this would have been created from a Hotel object so why not simply add a quotePrice() method to Hotel Here s how it could look: public class Hotel { private var id: String; public var pricePerNight: Number; // . . .

public function quotePrice(numNights: int): Number { if (isNaN(Number(nights))) { throw new ValidationError("Please enter a valid number of nights."); } var numNights: int = parseInt(nights); if (numNights < 0) { throw new ValidationError("Please enter a positive integer."); } // Call the remote Java service: return PriceService.fetchQuote(this, numNights);

Notice how the validation is now being done in this non-UI class, not in the UI mark-up. The quotePrice() function throws a ValidationError if the input fails validation. We ought to catch this in the UI button-click event handler, and show an appropriate dialog box. Here are the relevant components from the UI mark-up: <s:TextInput id="txtNights" /> <s:Button label="Calculate Price" click="btnCalculate_clickHandler(event)" id="btnCalculate"/> <s:Label text="{totalCostOfStay}" /> <s:Label text="${hotel.pricePerNight}" /> And here s the ActionScript to go with it notice how both hotel and totalCostOfStay are bindable: import mx.controls.Alert; [Bindable] private var hotel: Hotel = new Hotel(); [Bindable] private var totalCostOfStay: String; protected function btnCalculate_clickHandler(event:MouseEvent):void { try { totalCostOfStay = "$" + hotel.quotePrice(txtNights.text); } catch (error: ValidationError) { Alert.show(error.message, "Validation Error"); } }

Note If you look at the ActionScript code, the totalCostOfStay variable is tagged as bindable. So when its value is changed, the Total Cost label will be automatically redrawn with the new value. The Hotel object is also bindable, because we re using its pricePerNight value in the price per night label.

In the button click handler, the hotel s quotePrice() function is called with the text value of txtNights. If any validation fails (non-numeric or negative value entered), the UI code catches the ValidationError and displays an alert dialog see Figure 10 8.

Figure 10 8. Running a unit test is one thing, but good old visual inspection seeing exactly what the user sees is important, too. Adding a unit test for the validation code should now be pretty straightforward, as Hotel is a nonUI class. We can further split out the validation from the quotePrice() function to make it easier still. The two functions in Hotel are now the following: public function quotePrice(nights: String): Number { validateNumNights(nights); var numNights: int = parseInt(nights);

return PriceService.fetchQuote(this, numNights);

public function validateNumNights(nights: String) { if (isNaN(Number(nights))) { throw new ValidationError("Please enter a valid number of nights."); } var numNights: int = parseInt(nights); if (numNights < 0) { throw new ValidationError("Please enter a positive integer."); } Here s the FlexUnit 4 unit test code for Hotel.validateNumNights(): public class HotelTest { private var hotel : Hotel; [Before] public function setUp(): void { hotel = new Hotel(); } [After] public function tearDown(): void { hotel = null; } [Test] public function testValidateNumNights():void { // Expect no ValidationError to be thrown: hotel.validateNumNights("1"); } [Test(expects="ValidationError")] public function testValidateNumNights_Negative():void { hotel.validateNumNights("-1"); } [Test(expects="ValidationError")] public function testValidateNumNights_NonNumeric():void { hotel.validateNumNights("xyz"); }

The three test functions are pretty straightforward. The first test is the basic course : a valid number is entered, so we don t expect a ValidationError to be thrown. The other two functions test for a negative number and a non-numeric number respectively: for both of these, we expect a ValidationError, and the test fails if we don t get one. Figure 10 9 shows the warm and snuggly green bar when we run the test class in Flash Builder.

Figure 10 9. Green bar of Shangri oh, you get the idea The main point here is to compare this code with the corresponding antipattern #4 in 9: that version would have been impossible to unit-test, whereas with the validation code separated into a non-UI class, it s now very straightforward.