This is a continuation of a series of articles about Self Testing Applications. Here’s the first one: Self Testing Applications

Without diving into the technicalities, here’s a walkthrough of a self-testing application. It’s not a big example — it’s the smallest possible thing to get a feel for the main concepts.

Start with a goal

The goal of this app is to replicate the feel of Doogie Howser’s diary:

So I start by capturing it in the following feature files. Ideally, I’d do this in collaboration with a diehard Doogie Howser fan, but I’ll have to make do with my own best efforts:

Recently there was discussion on LinkedIn about how testing has changed in our brave new Cloud-native world.

It made me realise that I needed to write up some thoughts I’ve been developing about self-testing applications — an extension to good practice for testing modern applications (particularly in a SaaS environment). In a nutshell: I’d like to see tests granted a place as a primary part of running applications — not relegated to a distinct, ancillary codebase which gets jettisoned prior to release.

For the next article in this series, see: Building a Self-Testing Application

Straight to Production

When I started coding web applications…

Below is a list of companies which I have worked with. Some engagements were permanent but many were in a consultative or contract basis.


As Engineering manager I was instrumental in expanding our small startup-style company into a well funded SME on track to secure series A funding, with a solid technology roadmap.

Fluent Technology

As Principle Engineer I spearheaded the introduction of modern engineering practices and technologies, including Continuous Delivery, Cloud-native technologies and BDD.

Verint Systems

In my role as UI Architect, I led teams developing javascript-stack applications using React.js and node.js …



I have served as technical editor and/or proof-reader for several publications…

Human beings seem to have a tendency to think backwards (looking for patterns in previous experience) rather than thinking forwards (working out what patterns will form in the future). Obviously you can’t do the latter without doing the former, but if we think backwards too much, it can focus our attention on surface detail — how things appear — rather than on what lies beneath.

If you cast your mind back to elementary physics lessons, you may recall learning about wave interference , or perhaps Young’s double slit experiment.

Where the waveforms generated by the signal interfere constructively, the signal…

My final anecdote is a company which started out agile, enjoyed massive success, but then lost its edge. The owner of the company made millions on the first, humble product offering — put together using the minimum possible of computer code. Everything about the product was highly specific to the problem being solved, with no generally reusable libraries or components developed. Large parts of it might be categorised as “scripting” rather than as an “application”.

Having enjoyed so much financial success, the owner brought in a team of competent engineers and set them to work doing “proper software engineering” to…

Company three was a “start up” in the mould of the dotcom bubble. Revenue was derived via a classic “freemium” model, venture capital, and marketing “funnel” — exploiting internet scale marketing and the latest in “Web 2.0” innovations.

A large codebase was developed presenting a rich, web-based UI using a uniform technology stack. Code was universally delivered using TDD, and engineers were encouraged to explore eXtreme Programming techniques — regularly pairing to code up features, and using a custom Agile delivery model to ensure prioritised, “product-centric” feature development. Other companies consulted with this company on how to “do Agile right”…

The second example on my mind is a company which tackled an ambitious product, embodying brilliant innovations in how technology can be applied to a business context.

The original development was funded by income from existing products, and involved a large team following a service-oriented team structure. Teams were allowed to develop and deploy their own silos of functionality using the tools and technologies which they wished to employ. Inspiration was, in part, drawn from Spotify’s model of software development.

After several years, a highly ambitious web application was delivered. Many new and interesting technologies were employed behind the scenes…

The first company on my mind developed a significant document workflow product, focused on a narrow vertical market. This was delivered rapidly for an initial customer over a period of twelve months.

Having a product which was selling secured several rounds of investment. This company brought on staff to support the complex feature set, and to work with new clients on implementing the product for their particular business model.

The initial development resulted in a product which was generic enough to market more widely. Many new features were bolted on to the design in order to win new clients to…

  1. Ability to move quickly and easily
  2. [Context: business] Ability to deal with change in the business context well (and often, rapidly)

I care about agility because I care about the companies I work with. Because of how my career has developed these are mostly software development companies. And, I really care about the effects of the software we produce for people to use. I’ve seen some products work, and I’ve seen some fail — sometimes terribly.

With twenty or so years under my belt, I feel under pressure to know what I’m doing. At this point in my career, I…

Andrew Gibson

Business and technology in the software engineering space

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store