/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Writing testable code is writing high quality code

Writing testable code is writing high quality code

Writing testable code isn’t just about writing code that is easy to test, writing testable code is also a way to write higher quality code. If you can test it it is likely to be reusable, loosely coupled and easier to maintain.

The Google Testing Blog, mostly written by MiÅ¡ko Hevery, is amongst the most brilliant things I’ve read on software engineering. If you’re not convinced about the benefits of writing testable code after reading MiÅ¡ko’s articles I think you may be a lost cause. These are my favourites from the last few months:

The articles explain testing and good practices in software engineering in a simple, accessible, to-the-point manner without droning on about theory. Great writing and great insight. Read it.

12 Responses to “Writing testable code is writing high quality code”

  1. Marcus Stade Says:

    I find that there is a lot of resources on the subject of testing methods, classes and what not. But what about GUI testing which is quite important as well, especially in our business. I’ve been looking around but have yet to find a nice sustainable solution, be it a method or software or a combination of the two. Unit tests for GUIs, do they exist in a non awkward manner?

  2. Theo Says:

    Check out Fluint (previously dpUint) and it’s sequences. They seem to be quite good at testing UIs. I say seem, because I haven’t tried. I instead use the Presentation Model pattern and test my view logic, which more or less what you want to test, and enough for me.




  3. Marcus Stade Says:

    Thanks man, I’ll definately check it all out!

  4. Marcus Stade Says:

    Heh, funny, we’ve been using the Presentation Model all along except we’ve been calling it a State Model. It never occurred to me to actually test the model itself. Thanks a lot for your input! Oh, and the blog is great, keep it up!

  5. ronen Says:

    Testable code can conflict with good code, the best example is testing private methods sometimes the only solution is to increase visibility of components in order to make them testable, as for UI testing if your not testing the widgets them self then your doing only half of the work, like it or not widgets contain logic and should be tested (custom ones and compositions of widgets), i enjoy your blog also, keep on the good work!

  6. Marcus Stade Says:

    Maybe widgets are too smart for their own good? In a sense, isn’t a ui control a view in and of itself and should follow the mvc pattern as well instead of being a mashup of model, view and controller in one?

  7. ronen Says:

    The problem is with the integration of widgets (we compose and hook them up into new larger components), when ever there is an integration point between software components there is a potential for bugs. Also when writing custom widgets and firing/processing low level events (like in pure flex) can be hard to manage/refactor without proper test suite.

  8. Marcus Stade Says:

    I’m not quite sure I follow. In my mind, a component is a unit itself and should not really care about any other components other than children. Now, the children expose an API which we must assume works whatever way is specified and should not be dependant on the parent (unless specified, which might be a design flaw). That might not always be true, but isn’t those kind of issues quite easy to spot (however not always that easy to fix)? At least, that’s always been my experience.

    Considering a component to be a unit itself, it’s own model and logic should be quite easy to test, regardless of any integration. Please do correct me if I got you all wrong.

    System integration however will probably always be an issue, as is diligently mentioned in the Google Testing Blog:

    “Of course, all the complex issues of integration and system testing remain. Good unit testing gives me a good head start for integration, but I might still be in for unpleasant surprises there.”

  9. ronen Says:

    Your correct and your describing unit tests, im aiming here for integration tests. Usually you have a model and complex view which is composed out of a number of other components (flex buttons grids what ever), there are concerns that play role with the correct operation of this view that has no direct association to the model or its controller, for example the layout, the styling, the way that events are fired in reaction to user interaction and how they are handled, binding etc.. All these usually don’t depend on the model or controller but on the implementation details of the view and have to be validated with tests, im not saying that its easy, its damn hard.

  10. Marcus Stade Says:

    You’re right, it’s difficult to test and somewhat reiterates my original question about testing user interfaces. It also raises a question regarding the scalability of the Presentation Model. We’ve been using a version of the Presentation Model in our projects and quite honestly the model grows fairly easily and quickly along with the complexity of your view. However, in my mind there is little reason for having just one model for a view consisting of several views. In fact I argue that seperating whatever logic and state exists in your sub views from your main view is part of the whole pattern, or at least the pattern which we use. It’s aptly illustrated in the “Music Browser” example (http://weblogs.macromedia.com/paulw/archives/presentationpatterns/presentationmodel/demo/PresentationModel.html) where the browser is the main view and the form on the right hand side is a sub view. This is reflected also in the presentation model (right click for source). I’m intruiged as to what unit testing might bring in this scenario to help out with UI testing. Of course, there are still hard to (automatically) test issues revolving the actual visual side of the GUI. Ie, is a button greyed out when it’s disabled? However, testing that clicking the button doesn’t do anything when it’s disabled is still testable.

  11. Theo Says:


    Yes, if you test private methods you do something that “private” is meant to avoid: place dependencies on code that is internal and subject to change. So don’t. It should suffice to test the public interface of your unit, i.e. class. I agree that sometimes you would like to write a test for a subunit, like a private or protected method, because it is complex and you would like to make sure that it really does what it’s supposed to do, but don’t. Refactor your code instead. If that method is so complex or critical and you really need to test it separately, perhaps it would be better to extract it into it’s own class (which a suitably abstract interface). In Refactoring Fowler mentions the situation and if I remember correctly the advice is that either it’s public and you test it, or you refactor until you can test it (but still maintain the level of information hiding you should have).


    Some testing isn’t practical to do automatically, you will always have to do visual tests — for example to make sure that, say, a button not only is disabled, but looks disabled. So, consider the situation when you have a presentation model with a property that determines if a button is enabled, and a method that is called when someone clicks the button. You also have a view with the button in question, and it binds the enabled property on the button to the buttonIsEnabled property to the presentation model, and sets up the event handler to call the method when the button is clicked. What part of this setup should you aim to test in automated tests?

    • The state of the presentation model, e.g. manipulating it in such a way that the buttonIsEnabled property should be set to false and checking if that is the case, and also running the related method to see what happens (perhaps it should silently ignore calls when the button is disabled, or throw an exception).

    • That the view responds to changes in the presentation model, e.g. when the buttonIsEnabled property is false the enabled property on the button is false, etc.

    • That the button is greyed out when it is disabled and that it is positioned to the right of an input field.

    I’d say the yes, absolutely, to the first point. I’m very sceptical to the second, it could be done, but I don’t see the point. Just because you can doesn’t mean you should test everything, some things are too simple to test, like getters and setters (that don’t have any complex boundary checking, of course), and this is more or less the same, there’s too little to gain from writing the test.

    To the third point I’d say you’re nuts if you think it would be a good test to write, because this is the kind of thing you can only test visually. Autmatic testing of things like layout, positioning, colour, etc. can’t give you the level of confidence that you need, because what you measure isn’t relevant. The requirements of layout don’t call for the kinds of things you can spell out in an automated test.

    Even though you can write many kinds of tests that test your application at many levels, there are limits to what is practical and what you would gain from testing it automatically. You don’t test getters and setters, because the time writing the test doesn’t pay itself in terms of your productivity, you can be pretty sure that the setter will work correctly because it is only one line. The same goes for bindings (although there are exceptions) and some other things that are related to the layout and updating of a view.


    From the description in the comment above this I’m not sure you’re talking about “view” as in the “V” in “MVC” or “view” as in a view class. Maybe I’m just misinterpreting, and if I am just ignore this. Each view, as in view class (MXML file essentially), should have its own presentation model companion, and if either the view or the presentation model starts getting complex, you refactor and create a number of subviews, all with their own presentation model. The tricky bit with Presentation Model (the pattern) is to get the presentation model objects into the right views the right way. There are different ways of doing this, and it can depend on the application framework you use.

    It was something else that you said, which I can’t seem to find now, that got me thinking about the PAC meta pattern, Presentation-Abstraction-Control. Basically you have a model, a view and a controller in each component, sort of like OpenFlux. It definitely has its uses, especially in component development, where you otherwise easily end up with one fat class that does a little too much. When it comes to crafting views in applications I think that Presentation Model (and the Model-View-Presenter with Application Controller meta pattern) is more suitable.

    There’s a good article on different application architecture meta patterns here: http://ctrl-shift-b.blogspot.com/2007/08/interactive-application-architecture.html

  12. Marcus Stade Says:

    @Theo, no, I think you got it right. I was referring to view as in a view class, not the view in the MVC pattern. Maybe component is a better word, but I’d like to differentiate between component as in buttons and more complex components such as grids or other kinds of composites. Anyhow, I think we’re very much on the same page, except you are a better writer than me and get your point across much more effectively. Thanks for the links!

Leave a Reply