What to test when building websites using CMS?

Question

My job is mainly building websites using CMS such as Drupal, eZPublish or Magento.

Most of the work is templating, CRUD and adhering to the specs with this. Occasionally, there is some business-specific logic, but it's usually 20 lines or so. Most of the logic is a bunch of if in the templates.

In this context, I find it hard to argue over unit testing. What should I test? Only integration tests? They usually can only be done at a very high level, such as using Selenium IDE. And Selenium is a pain to handle in project-mode products, because the requirements often change in 6 months and then the project is over. There are also other difficulties such as URLs being dynamic. (CMS don't always respect a RESTful architecture, especially for contents.)

I am in favor of unit testing. For libraries or framework-based projects, I easily write them and sets up a Jenkins server for them. But for CMS-based projects, I just don't know how and where to get started.

• Arseni Mourzenko: Not a duplicate, but still related: programmers.stackexchange.com/q/203408/6605
• Florian Margaine: @MainMa yeah, not a duplicate at all :-). The other question is still about testing a single method, with clear input/output.

Answer 1

You don't write unit tests just for sake of it, you write them when it is efficient way to reduce your bug count. For that unit tests are used in two ways:

• To test lower layer components in isolation either to gain some trust in them before you write the higher layers or because it is easier way to debug than setting up the higher layers.
• To make sure that you maintain the functionality when you need to restructure the components for technical reasons.

Now in CMS-based project the lower layer is the CMS, which probably has it's own tests and you are not modifying it, so you don't need to write tests for it yourself.

And in short projects just filling in pieces in a CMS you rarely restructure anything except when the requirements change. In which case you'd need to rewrite the test too.

So neither of the reasons apply to any significant extent. So I'd not bother with unit tests. I would not even try to go out of my way to automate the integration tests. Browser automation is fine, but if you just need to test it a few times and than it goes live and noone will touch it anymore unless the requirements change, you only need to test it a few times, so the automation may not save as much time testing to pay off. Especially since you need to do some manual integration testing anyway.