Tuesday, 1 April 2014

Dont Tie Yourself to a Framework

  • Programming is great
  • Software development is the crap bit. You'll spend more time configuring, integrating and faffing rather than writing logic most of the time.
  • Test Driven Development makes development easier as it forces you to decouple your code.
    • Your core logic should be pure, dependency free C#, Java, Python etc.
    • Your frameworks and libraries should be on the edge of the system.
  • Most people do this for some of their code, e.g. your data access.
  • What about the other parts of a system?
    • Web frontend
    • REST api's
    • Console applications
    • Desktop clients
  • Why should we couple our applications with these layers?

Hexagonal Architecture

  • Hexagonal Architecture is a solution to limit coupling
    • Easily switch out your delivery mechanism, e.g. test runner adapter for testing, HTML adapter for production.
    • Great example from Kevin Rutherford.
    • Excellent video by Uncle Bob though terminology differs.
    • Implementation details should be hidden behind adapters.
      • Tested manually in the majority of cases
      • Few integration tests for comfort
      • Third party code after all.
    • Inner hexagon should only communicate via ports (interfaces) - keeps domain pure.


  • Last few major projects involved with were due to the delivery mechanism becoming out of date.
    • Flash to Web
    • Web to Mobile
  • Easier to test
  • Easier to change

Why not?

  • CRUD apps - sometimes it's just CRUD.
  • Lightweight projects might not need hexagonal architecture
  • SOA or Microservices could mean hexagonal architecture actually introduces overhead or complexity - judge on context.

Flexible Selenium Tests via Page Objects

A fast, automated suite of unit and integration tests are not enough. At some point you'll need to test your presentation logic. Ideally your domain/business/game logic is stubbed so all you'll need to do at this point is check that the presentation is complete. For example, does view X load view Y? Does an error message appear when an error is raised?

With web sites and web applications the standard tool to use is the excellent Selenium. The problem with UI tests in Selenium is they are often slower to write. Not only this the maintenance cost of such tests can often be much more expensive that other styles of tests. If the cost of such tests is high, the likely hood of developers writing UI tests is low. In my experience there are three types of UI tests in use.

  • Low Level

    Here UI tests are wrote directly against Selenium. This low level approach means tests are scattered with assertions and UI details. For example element locators such as divs and ids will be used with methods on the Selenium driver in question. Despite this low level approach such tests are often quick and dirty to create. The downside to this style of test is that as the volume of tests increase, the cost of maintenance can become very costly. A simple UI change can cause a ripple that will cascade through many test cases.

  • Browser Abstraction

    The next level up from direct use of Selenium's driver is to create a facade around the browser or UI itself. For example rather than duplicating the steps to log in within each test you could create a method PerfromLogin(...) which each test could make use of. Another example would be abstracting messier details of UI automation such as clicking a button and waiting for an event. This style of test has the benefits of low level tests but gives some flexibility when it comes to maintenance. The downside with this facade approach is that UI changes can still cause havoc, as each test in question will be tied to the UI elements directly.

  • Page Objects

    Taking the browser abstraction to the next level, page objects are an abstraction over the UI itself. These high level tests are wrote in terms of the domain, rather than implementation details. There is of course one place where each page object is bound to a UI element, but as each test uses an object, rather than element locators you only have to change one place when your UI changes. Unlike the previous two styles of tests, page objects incur the most amount of code, though for more than a handful of tests this style of UI acceptance test will pay for itself in no time.

    With the above example the LogInPage object will be bound to UI locators. This will vary based on programming language, but using C# as an example each property would have a specific attribute to link up each element. The domain specific methods such as Username will fill in the correct UI element with the provided value. By writing the objects in a fluent interface style, you can achieve QA friendly tests which are easy to debug when they go wrong.

A more fleshed out example of the Page Object pattern can be found on Github.

Choose a style based on context. Given more than a handful of tests then page objects are worth the extra cost, the ability to evolve your UI while maintaining end to end tests is worth some additional complexity at first.

Design is Important

When I was a student I used to cheat. Not in exams or practical assignments, but I used to cheat when it came to my process to develop code. Early on I noticed a common pattern. After receiving an assignment I would perform some analysis, figure out a basic design and document my steps. The problem came when to code up the solution. I may have overlooked something, or made a mistake. Sometimes I would just come up with a better solution. This meant any time I spent documenting was lost. It turns out this wasn't cheating, after all there was nothing within the assignments enforcing a waterfall approach.

I wasn't alone with this experience. Most of my peers had the same issue, and the report aspects of an assignment were often disliked for this very reason. My solution was simple. Code up something, get it working then document the design aspect. Rinse and repeat. Back in the early 2004 I wasn't aware of agile methodologies, but this solution worked a treat. In turn my classmates started to adopt this similar approach, either from my encouragement or their own discovery.

Moving from university into a practical environment was a joy. It almost appeared as if little to no documentation was produced. The documentation that was produced, was often created by other teams. Developers simply wrote code. At the time I thought this was great, but after some reflection the errors of my ways have been highlighted.


In my experience a variety anti patterns are to blame.

  • No or limited design

    The worst thing that can be done when it comes to design or planning is the absence of any design or plan whatsoever.

  • Coding your way out of problems

    Given some limited or poor design, I've often experienced scenarios where 80% of the tasks will be complete, then you hit a roadblock. In order to progress the team will hack their way around it, introduce technical debt or put in some not so temporary fixes.

  • "Weeks of coding can save hours of planning"

    A colleague I used to work with used this once and I fell in love with the quote. Take an average web application, if the life cycle of this would be a meager two years, spending a few hours putting a design together is nothing. You could argue that spending a few days would be equally fitting, better yet a couple of weeks well thought out design is only a small percentage of the overall cost of delivery. When it's too late you can code your way around the problem. Though this debt will soon add up, meaning features are even slower to add going forwards.

  • Playing the "Agile" card

    A misconception of the agile manifesto is to favour "working software over comprehensive documentation". Most developers read this as never document anything. This is far from the truth. Documentation, design and planning should be built into the product in iteration. Just In Time (JIT), rather than all up front or never at all.

  • Greenfield projects

    Having been involved with a couple of "rewrites" I've seen this happen first hand. No design, limited design or bad planning in the first few iterations of a project can kill it. Only by iteration three, four or five will you notice something isn't right. At this point you've lost. Suggesting to restart, reboot or refactor is a hard sell, especially to management teams. Architectural changes are very difficult at this point, as you'll most likely have users, automated tests and other teams relying on what you have produced.

  • Refactoring can save the day!

    Give me a bad class or method and I can make it beautiful. Give me a bad application and we have a problem. Refactoring is a class or method based activity. I don't buy architectural refactoring - and I'm not alone. Emergent design is a very powerful tool, but without some upfront planning you'll be stuck in limbo.


There are a few ways to overcome the previous problems.

  • Whiteboards

    As much as I love technology you cannot beat a whiteboard (or piece of paper) and a couple of engineers. Visual collaboration in this manner is very easy, plus physically having the presence of another individual helps. You can also snap a picture of these diagrams to reproduce them in a more friendly, shareable, digital form afterwards.

  • CRC's

    Class Responsibility and Collaboration cards are another low tech solution, but one I find incredibly valuable, yet for some reason don't appear to do enough of. Best performed in groups, though I've had some success on solo efforts.

  • JIT documentation

    Not pages of wiki articles or documents, just lean, self contained documents that serve a purpose. Develop these in iteration and you'll avoid a "documentation sprint" from hell.

  • Code itself

    Prototypes are worth their weight in gold. Spike solutions when used across a team are also incredibly effective. Rather than a single prototype being produced, each team has a crack at the problem in isolation. After regrouping you present back your solution and findings. The team then combine to form a "best of breed" approach.

    Iteration zero is often used for getting the build up and running. If you take this one step further, the ideal scenario is to produce a walking skeleton. This should consist of empty or basic class/method/function definitons that have not yet been implemented. With a basic API in place, fleshing out the details is rather enjoyable. You focus on the problem, not the design or architecture.

None of these are ground breaking ideas, but combined these approaches have served me well both personally and professionally.