Natural and budget saving roadmap of moving development team to Test Driven Development.

Customers are not going to budget writing tests, period. Honestly, at least 80% of them. Tests are not the product they will use to improve their business.

Moreover, Project Managers, Business Analysts, Product Owners and even Team/Tech Leads are seldom interested in writing secure, testable and easy to reuse a code because of the tough deadlines.

When it comes to the speak "let's have tests in our code", often the answers are

• some day in a future, we have no time to spend on it
• maintenance for tests is a pain
• tests should be created for libraries only
• running tests is a time consuming
• tests must be perfect from start, otherwise it makes no sense
• tests slow down speed of development
• impossible to run tests with real customer's data

But what if we ask developers about: 

• are tests usable and needed for your work?
• could they improve the speed of development
• is it possible to run fast tests on real data?
• is it possible to test external production services integration without affecting the data there?

And answers for these questions are the topic of current session.

In our team we answered as four "YES":

• are tests usable and needed for your work? -> YES, we were using tests previously, but the actual code of the tests was never merged into project repository.
• could they improve the speed of development? -> Oh, YES, so much. Previously - debugging enterprise solutions was a pain in the a$$, but now we are able to reproduce the state of the system with a bug caught in ~4 seconds (in comparison to minutes and hours in the past)
• is it possible to run fast tests on real data? -> YES, by using dedicated builds from CIBox's like workflow solutions it is possible to run these tests on a fresh customer's data without affecting production.
• is it possible to test external production services integration without affecting the data there? -> YES, thanks to Drupal/Symfony/PHPUnit and our custom made phpunit_tdd module we are able now to replace sensitive service calls with mocks on real database for ability to run tests and to let QA make smoke and functional tests without affecting production data.

During the session we are going to make phpunit_tdd as an opensource and upload it to Drupal.org as a project for wider audience.

This session assumes that attendees are

1. Tech/Team leads
2. Software Architects
3. Senior Backend developers
4. Solution Architects
5. DevOps with a good Dev part

By attending this session you should obtain a strong knowledge of how to make your team write tests without ability to skip this step. Actually, not write, but just keep part of the usually lost code that they are already writing as tests.

Also, from Project Management perspective by using solutions we will be talking during the session all the team could save a bunch of time for development and QA.

Welcome to our session.