Polymorphic rants

Javascript has become in the last years the language for rich web applications,  but still it rarely receives the level of attention it deserves. Libraries such jQuery boost our productivity but the code we often end up writing tend  to be a big ball of mud, with an entangled mix of presentation logic, busines logic and server side interaction,  all incredibly hard to test and to maintain. It's time to move away from this approach and start writing better quality Javascript. The very first step required to avoid Javascript spaghetti code is start thinking to Javascript as a first class language, and start dealing with it with the same mindset and approach we would use for any server side language. With this new approach in the same way we identify roles and integration points  in server side code we want to start building abstractions in our Javascript codebase. With the right abstractions in place we are defining clear boundaries between different parts of the system, and as a consequence our code is simpler, we promote reuse  and the DRY principle, and  we are finally enabling better testing. Let's look at any standard Web 2.0 Javascript code from this new perspective: now the DOM and HTTP are two clear integration points. Our javascript code manipulates the DOM adding  nodes or changing existing nodes content in the same way any other language would interact with a database. Each call to a server over HTTP via Ajax is exactly the same of calling a web server from our server side code. With these very two first abstractions in mind, we can start rewriting our code, isolating these interactions behind clearly defined objects. Now the javascript code is not a ball of mud anymore, but a network of objects that collaborate. With these smaller objects  in place we can now favour interaction based tests, moving away from any dependency on the DOM and on the HTTP protocol. The identified abstractions let me actually mock  and stub things out and test if the different tiers in my javascript code are exchanging the right messages. This separation of concerns keep the business logic nicely isolated from the user interface transformations, enabling also a cleaner state based testing for that specific part of the code (there are no more dependencies on the DOM).

Acceptance Testing is a fundamental practice: it gives you confidence that your application behaves as expected from the end customer point of view. In the Flex world there are some projects that are currently emerging in the Acceptance Testing space, each one with specific advantages and weak points. Let's have a look to some of these. FlexMonkey FlexMonkey Open source but based on closed source API (the Automation API are released only with FlexBuilder and not with the open source Flex SDK), it's based on the record-playback approach and as far I  have seen is not easily integrable with a Continuous Integration server. Flash-Selenium Flash-Selenium is open source, and it works as an extension of SeleniumRC; the tests can be written in Java, .Net, Ruby or Phyton and the integration with a Continuous Integration server is therefore quite out of the box. SeleniumFLex API SeleniumFlex is another open source project. it's an extension of SeleniumIDE, test should be written in Selenese. FunFX FunFX is based on the automation API (therefore you can use it only if you're owner of FlexBuilder), the fixtures are  written in Ruby. At the moment there isn't a  de-facto solution: the community is quite dynamic and all these different tools are trying to find their space. Which one is  my favourite ? It's really hard to say, I think that the context matters a lot. I  don't like the solutions that require the Automation API simply because this tights you to a vendor just for testing; it's also true that the pure open source solutions requires some extra-hack (like exposing methods through  ExternalInterface) that are less than ideal. Looking at the two pure open source tools I like Flash-Selenium for its out of the box integration with Continuous Integration server, while I prefer Selenium-Flex approach for handling the necessary ExternalInterface configuration.

For the last two weeks I've worked with EasyMock and coming from a JMock background it's easy to make a comparison between the two libraries. I have to say that I'm less than impressed by EasyMock: the whole concept of the two different states (recording and active) for the mock library looks unreasonable. Let's look on how we can create a mock with EasyMock: MyInterface mock =EasyMock.mock(MyInterface.class); //expectation mock.myMethod(); //activation step mock.replay(); //actual call to the mock mock.myMethod(); //verification that the method has been called mock.verify(); There's also a more DSLish style of defining expectations, that I personally prefer (it differentiates clearly the definition of the expectation from the actual method call). EasyMock.expects(mock.myMethod()); This style is the only one available when the expectation is more complex: EasyMock.expects(mock.myMethod()).andReturn(true); But what if I want to define that a certain method will be called on the stub, no matter how many times ? I can either use a different way of creating the mock: EasyMock.createNiceMock(MyInterface.class); or using the DSL way: EasyMock.expects(mock.myMethod()).anyTimes() I think that having two ways of defining the same expectation pretty confusing, specially when you're using the API for the first time. What I'm looking for in a mock library is the possibility of defining the expectations in a concise but expressive way (DSL please...) and then inject the dependency in my main object. Period. Done. JMock2 is pretty close, but I have to admit the the inner class notation with all those curly brackets around is not helping. A fellow ThoughtWorker have just released Mockito: it looks like it's taking the best from EasyMock and JMock and put in a single library..will it be true ? I'll give it a try and I'll let you know ;-)