Why you should be writing integration tests for Drupal

In our previous blog post, we made a pretty big claim that Drupal 7 unit testing is broken. You probably knew that already but you know the importance of testing a big Drupal project as well. So like us, you started using Behat and Selenium for functional and user acceptance testing. It worked well for a while but now there are so many test scenarios that you are finding it difficult to maintain all of them. To make it worse, your test suite takes hours and hours to complete. But do not despair! Here comes integration test to your rescue.

Why do we need integration testing? Don't we have functional tests to cover all the systems?

Yes, we do. But if you try to implement all your test cases on a tool such as Behat, you will quickly find that your test suite is exploding and is becoming unmanageable. Also functional tests are extremely slow, so something that can be tested using integration tests in 15 minutes will take 5 hours to be tested using functional tests. Remember, quicker feedback is always better!

What does integration testing provide if we have adequate unit tests?

If you are using Drupal 7, I find it hard to believe that you have unit tests that cover all of your custom code. But even if you do (I am extremely extremely impressed if you do! Please write to me how? And yes, I intentionally wrote "extremely" twice.), integration testing provides some advantages over units tests:

• Unit tests do not touch the database while integration tests do. This means that all of your site configuration can be tested.
• Unit tests cover each function in isolation. So you don't know whether these functions will work well together. Using integration testing, you can test whether your software, which may consist of multiple systems and functions, is indeed working together. As an example, if you are using Apache Solr as search engine, then you can test whether providing a known keyword in Drupal's search form returns right results.

Doesn't writing tests take time? Won't my cost increase?

Yes and no. Writing tests does take time. In fact, some times, it takes more time to write a test in Drupal than to create the functionality. That's because you can create a functionality in Drupal using the UI but writing tests requires writing code. So ask your developer whether he can write bug-free code 100% of the time. If he says yes, then do not hire him because he is lying or he has no experience of writing a big piece of software. On a more serious note, yes, cost of the project will increase if you write tests when you are getting bug-free code 100% of the time. But I have never seen this happen in a big project. Usually what happens is that if you do not have tests, then after a point of time, it will become exceedingly difficult to push new features to production because adding more functionality will break old functionality, or worse, you will find older piece of functionality breaking on the live site after you have pushed new functionality to production. So here comes the next question.

Should I be writing automated integration tests?

Here are some cases where we have seen integration testing to be worth the effort:

• Three or more developers are working on a project. In larger teams, developers can unknowingly break other developers' features.
• It's a big site and you are adding more and more features to it over time. More changes you make to the site, more the chances of breaking.
• It's a mission critical site where you can not afford a bug. There are a lot of sites that fall under this category:
  • Media sites with huge following. You don't want your users to know about this bug because you hate apologizing to your customer base over twitter. :)
  • Revenue-producing sites. You obviously don't want a site bug to come in the way of you and the "Benjamins".
  • Sites of major brands or organizations. You definitely don't want another HealthCare.gov.

On the other hand, if you are a small or medium sized business, with more or less a static site and where a few bugs here and there are not bothering you much, then don't worry about automated testing. You can skip the rest of this blog post.

Does an Integration testing framework exist for Drupal?

Till now, it didn't. Now it does. We created this framework, named "Red Test", to solve the exact problems that I have mentioned in this blog post. We have been using it since over a year now and it's already in its fourth version. We are making it open-source so that other developers and agencies can benefit by using it to maintain big Drupal sites. If you can't wait to get your hands on it, then go to the next article explaining how to install Red Test on your system. Others, read on!

What's so special about Red Test?

Red Test is an automated integration testing framework based on PHPUnit and specifically designed for Drupal. It understands Drupal. This means that there are a lot of things it can do without you having to tell it. It knows about the node table, the users table, the forms, the entities and the likes. It knows how to create new nodes and how to even test them. This means that your test code gets reduced drastically. Here are a few things we had in mind when we created Red Test:

• It should be fast. Based on our comparisons, it is about 60 times faster than SimpleTest. We have designed it to be able to run on multiple cores in parallel.
• It should be extremely simple to write test code using Red Test. Our goal is to reduce automated test development time to less than 10% of total development time.
• Tests should be easy to read and understand. Another developer should be able to understand what's going on in the test by just looking at it. This means that each test function should be very short.
• Each test should be based on business requirements and should show them clearly. This means that all the default work of setting up the test structures should be done in the background automatically, as much as possible.

So are you excited about Red Test? In the next post, you will learn how to install Red Test.