Whatever the size and complexity of the Drupal-based website you are building, every feature, indeed every line of code you are producing without automated tests is legacy code, and costs you a fortune in maintenance in bad blood later on in the project. Yet many Drupal teams have tried, and failed, to implement automated testing best practices.

Why is it so hard to implement automated testing methods for your projects? This talk is aimed at giving developers and business people some tips on introducing automated testing to their projects; it is also for tech-savvy clients who want to know what to request from their Drupal shop.

Having been involved in several Drupal projects of all sizes where teams have tried to implement automated testing, I have come up with eight prerequisites I think one should keep in mind if one is to succeed with automated testing.

This talk is based on my blog post, will contain some demos and examples, and will cover the following material:

• Why setting up a continuous integration server is the first thing you should do.
• Do not clone the database. Why cloning the database upstream will lead to failure.
• Testing is hard and takes time. Double your estimates, and reap the rewards later in the project.
• Start gradually. Don't aim for 100% test coverage. Start with only one test.
• Produce tests, not excuses. Your code is not as elegant as you think.
• The test pyramid. Start with the low-hanging fruit: unit tests, then move on to functional and database tests. Implementing Behat and Selenium before you're ready will lead to failure.
• TDD and peer-review make sure tests are actually written.
• Don't subvert your process, even when the going gets tough. You will be rewarded.

This talk is aimed at developers and project managers who are frustrated with technological debt, tempted by automated testing and want to do things right.