The automated testing paradigm


As coders we have to test our product before we ship it. Some of us choose to automate some don’t. For those who automate, it is important to understand where the boundaries should be applied and how to minimise overlap when testing. Consider the following very popular testing-round-shaped-pyramid.

As you can see from the above and like many countless websites tell you the same, you should try to minimise the top layer of testing “UI”. Then have more “Service” tests and finally have loads of “Unit” tests.

So what are these in fact then?


Any assertions made through the user interface whether that actually is checking for the UI or not, is a UI test because it loads up that layer. Loading up the UI means processing html, css, js hence making the execution very slow for a test. Obviously when you are on the UI layer, things vary between browsers – its not an easy game to maintain. Plus these testing tools are not 100% reliable, hence making it a bad choice for CI for instance unless we choose to put in redundancies (these can mitigate the risk of false positives). Tools that do this type of testing:

  • All tools that use selenium or some browser to execute their tests.
  • Popular tools:
    • Browserstack
    • Telerik
    • Behat with mink extension when run through ChromeDriver or any Selenium enabled driver.


This layer is all about bypassing the UI and hitting the server directly. This is a very reliable and efficient way to execute your tests. Since you’re not visiting through a browser, your tests don’t compile CSS, JavaScript or even HTML. So its quite fast, but the reason why you won’t want too many of these either is that it can take a serious amount of time to automate every possible scenario there is to test. So – with caution – create a criteria around what to automate and use that. An example criteria could be:

  • How risky is the feature scenario to be automated?
  • Can we cope with the failure of this feature?
  • What level of a bug would this scenario produce if it failed?
  • Is it worth the time spent automating?
  • Would it be covered as part of manual testing?


This layer is absolutely critical. A unit test basically tests whether a single unit in isolation works as you would expect it to. For every execution branch, you would have an appropriate unit test covering it. This means your unit of code if fully unit tested, should cover every eventuality of execution of that unit of code.

Its important to stress, it does not cover the entirety of your application. This does not mean that if you have a 100% unit tested application, it can not fail. This is because when unit tested components come together in an application, their integration can create bugs. For that you need integration tests, a Service or UI test is a kind of integration test and MORE.

PHP land popular tool: PHPUnit

So to get the best out of your testing, combine at least 2 of these testing layers to form a solid testing framework.

You may also like...

Leave a Reply