hevery.comMiško Hevery

Home About Ask! Guide: Writing Testable Code Presentations Video Recording & Slides: Psychology of Testing at Wealthfront Engineering posted on February 14th, 2011 · Here is a presentation I have done few weeks ego at Wealthfront Engineering. Enjoy the slides and a recording of presentation ! → 9 Comments Tags: Uncategorized RTAC2010: All hands on testing posted on August 25th, 2010 · Just wanted to share my presentation from the RTAC 2010 conference. Slides Handout → 2 Comments Tags: Uncategorized What Flex taught me about data-binding posted on August 10th, 2010 · Like most other developers, when I first came across the Flex data-binding, I thought of it as an interesting feature, but haven’t realized the true implications of it until much later. Data-binding in Flex has revolutionized the way I think about building UIs. To understand why data-binding is so revolutionary, let’s look at standard Model-View-Controller setup for building UIs. Let’s start off with a model. A model is simply an object which has properties for all of information we may wish to display. Model package example.flextesting { [Bindable] public class LoginModel { username:String; password:String; showError:String; } } Now, model by itself is not that interesting, as we need to add behavior. To keep separation of concerns we put all of the behavior to the controller. Controller package example.flextesting { public class LoginController { public var model:LoginModel; public var authenticator:Function; public function login():void { showError = authenticator(username, password); } } } Boiler plate problem Without data-binding we have to write a lot of boiler plate code which copies the data from the model to the view. In our example this may be simple as we only have three fields to copy, but in a complex forms this may be several hundred things to copy. With time, this gets so complicated that adding a new field requires us to change many things in unison: the view, the model and and code which copies it to the view. Circular Dependency Problem At this point we need the view to be able to lay it out in MXML. Now imagine there is no data-binding. We have a problem, we need to notify the view to update itself from the model, and we need to get the view to call the login() function in the controller. This creates a circular dependency between the controller and the view, and there is just no way around it. This means that we can not use constructor dependency-injection. Testing Nightmare But there is a more serious problem, we need to test our code to make sure that it works as intended. We can easily instantiate the model, but instantiating the controller requires us to also instantiate the view. In many cases it may be impractical or impossible to instantiate the view in the test, and therefore the dependency on the view from the controller is causing the problems. The reason why it may be hard to instantiate the view is that the view may have dependency on other views and other controllers. One way to solve this circular dependency is to create an interface for the view. That way we can have two implementations of the view. One is the real view, and second is a mock implementation of the view. In the tests we can just instantiate the mock view and we are home free. While this is a good solution it requires us to write extra interfaces and extra implementations, and so it is cumbersome. Worse, any changes to the view require us to change 4 files (controller, interface, view, and mock view). Can we do better? Data-binding reverses dependencies Data-binding comes to the rescue. Data-binding solves our circular problem in a very clever way. It makes it so that the controller has no reference to the view. View still recognizes the controller, as the former needs to call methods on the latter when the user interacts with it, but the circular dependency is broken. Better yet, the remaining dependency is from the view to the controller, and not the other way around. This is very important, because it allows us to test the controller in isolation: we can easily instantiate the model and the controller without pulling in the view dependency. <?xml version="1.0" encoding="utf-8"?> <mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:flextesting="example.flextesting.*"> <flextesting:LoginController id="cntl"/> <mx:Form> <mx:FormItem label="Username:"> <mx:TextInput text=" {controller.model.username} " change=" cntl.model.username = event.currentTarget.text "/> </mx:FormItem> <mx:FormItem label="Password:"> <mx:TextInput text=" {controller.model.password} " change=" cntl.model.password = event.currentTarget.text " displayAsPassword="true"/> </mx:FormItem> <mx:FormItem label="Label"> <mx:HBox> <mx:Button label="Login" click="controller.login()"/> <mx:Label text="Login Failed" visible=" {cntl.model.showError} " color="#FF0000" fontWeight="bold"/> </mx:HBox> </mx:FormItem> </mx:Form> </mx:VBox> The magic of data-binding comes from the curly brackets ‘{}’. As you can see in the MXML above, the TextInput and the Label are both controlled by the ‘{}’. The data-binding acts as a kind of reverse dependency, a property which is very welcome, as we are trying to isolate the controller. What I want is reverse data-binding Unfortunately, Flex has not taken the data-binding far enough. When the model changes, the View changes as well. But since the view is a TextField, we also want the model to change when the user changes the form. This revers data-binding is not available in Flex out of the box and so we have to simulate it by adding change events that copy the data back to the model. You can see this in the MXML above, the forward data-bindings are marked in yellow and the reverse are marked in blue . This creates a lot of extra code which clutters the application. Conclusion So what have we learned about data-binding: MVC inherently suffers from circular dependencies which create problem in code, that makes unit-testing of the code very difficult. Data-binding reverses the normal flow of dependencies allowing us to break up circular dependencies, and thus get a less coupled system. Data-binding eliminates a lot of boiler plate code which shuttles the data from the model to the view, which makes our code easier to read and understand. → 21 Comments Tags: Uncategorized <angular/>: A Radically Different Way of Building AJAX Apps posted on July 29th, 2010 · http://angularjs.org source snippets → 37 Comments Tags: Uncategorized How JavaScript Works posted on July 14th, 2010 · Just a quick presentation I have done on JavaScript. video: slides: → 18 Comments Tags: Uncategorized Dependency-Injection and JavaScript closures posted on May 29th, 2010 · As you can tell I am a big fan of DI, but I kept hearing that DI is not needed with dynamic languages, so after using JS for many months I am happy to say that DI is important there as well. In other words dependency managment and controll matters. But it is different. Say you have a class for greeting with DI. class Greeter { String greeting; Greeter(String greeting) { this.greeting = greeting; } void greet(String name) { System.out.println(this.greeting + name); } } Since the class only has one responsibility it only has one method. Now we can rewrite this in JavaScript in OO way like this: function Greeter(greeting) { this.greeting = greeting; } Greeting.prototype.greet = function(name){ alert(this.greeting + name); }; While this code is fine, it does not follow the spirit of JavaScript which is a functional language. Why have a Greeter noun when you can just have greet verb. (see: Execution in the kingdom of nouns ) So let’s rewrite it in functional style: function greetFactory(greeting) { return function(name) { alert(greeting + name); }; } so usage changes from: var greeter = new Greeter('Hello '); greeter.greet('misko'); to: var greet...