Part 2 of 2 - Sebastian Bergmann, the maintainer of the PHPUnit testing framework, came to our office in Cologne, Germany to talk with Campbell Vertesi (@CampbellVertesi) and me about PHP, PHP FIG and the PSRs, and of course testing. It is another in the series of interviews we carried out with important and interesting people from the PHP community in preparation for DrupalCon Asia in Mumbai.
Our session, "Meet PHP-FIG: Your community just got a whole lot bigger, Drupal" is about Drupal 8’s membership in the world of PHP interoperability. We’re covering the basics of what the PHP Framework Interoperability Group (PHP-FIG) is, what the various PSRs are and do, and talking about testing and dependency management, and what it means to be a part of the new PHP community — including having better architecture, cleaner code, and less risk thanks to more interoperability. All of this adds up to a big move to get projects “off their islands,” saving developers a lot of code and companies a lot of money, among other benefits.
"I always think about testing as an investment into the future. I also like to think about tests as being executable specification and or documentation of my software."
Q: How can testing save people time and frustration?
Sebastian: I always think about testing as an investment into the future. It’s incredibly hard to believe if you have never done it and have not been doing it for a couple of months because we have to make this experience – just that it’s one of those things that most people don’t believe when they are told or when they read about it. You have to make the experience yourself. “It’s an investment into the future,” like I said.
So today I have the requirements for some process of my application and I implement that. Then in six months’ time or next year, something changes. I make the change and I don’t know--if I don’t have tests in place--that by making that change I did not break anything else that used to work. If I have tests in place I first go in (and if I do test-driven development), then I change the test first to reflect the new requirements. I run the test and the test will not work ... of course. The software has not been adapted yet for that. I also like to think about tests as being executable specification and or documentation of my software. So I’ve changed my specification. Okay so I’ve written down in code what the software should do and then I make the change. Now the test can tell you you things. Yes, the thing that you wanted to change now behaves in the way that you wanted it to behave after the test. More importantly, all the other things around it that are not supposed to change have in fact not changed.
Q: It makes any change or any pivot or any addition to what you’ve written much, much easier and much more efficient and much more - with a lot less risks in it.
Sebastian: It reduces the risk but it also reduces the time that it takes and that’s the most fascinating thing. There are plenty of studies out there from Microsoft, from Ericsson, from IBM that said when a team starts to introduce test driven development, for instance. For the first couple of months or so they will be 15% to 30% slower than they used to be because they have to learn a new tool. They have to wrap their head around a new process. After that they become much more productive because they spend almost no time on debugging anymore.
Q: Because they’re testing before they commit?
Q: Actually when we think about it that way then the value of the test increases proportionate to the complexity of the application.
Q: If you’re writing a 15-line PHP snippet, writing a test is not going to help you. On the other hand if you’re writing a piece of code that has to integrate into a really complex multi headed application--I’m looking at every Drupal developer in the world--then writing a test for that 15 lines can make a really big difference for you.
Sebastian: That is true. I don’t remember who said it but there’s also a saying in the testing community that it doesn’t go about the size of the project but they say you don’t need to test code that never changes. So if you are really, really sure that the piece of software that you have just written never ever change then don’t waste time writing test for it because you have just written it and you have done some manual testing around it to make sure that it works. Then there’s no need to invest in automated testing.
Q: Does that exist? How often does that come?
Sebastian: Never! You wouldn’t believe the kind of conversations I had - with customer management or been told by developers from conversations they had with their management or their customers, “We need this piece of software. It’s a one off thing. The software that only ever be in production for two weeks before this event and one week afterwards and then we delete it ... But it was so successful! Now we keep it and now it’s running for 10 years. Where the hell did these problems come from? What were the developers thinking? Why didn’t they do their job properly?” Because nobody told them that this was going to be in production for such a long period of time.
Q: The PSRs, the PHP FIG itself defining logging interfaces, defining how to store stuff, how to think about stuff. I think with these three ingredients in place allowed the Drupal community for example to build the first Meta PHP product. Its pieces of Symfony. It’s all these external libraries. It’s our own code ... I contend the Drupal 8 is a sign that PHP is in a new phase now.
"Beware of your temporary solutions; they're the ones you're going to have to live with the longest."
Q: Back to the new phase of PHP interoperability, PHP FIG, Composer, and Drupal 8 ...
Sebastian: It’s definitely a new phase. For me that phase started when PHP projects started to use RFCs for major language changes. So for me that was an important step forwards for the PHP project itself. A little bit later it started this Composer, PHP FIG, and so on. To be honest, personally, I’m a bit skeptical whether PSRs for logging, caching HTTP and so on are really that valuable and if there’s actually a problem that they solved and if there’s a problem, if those PSRs are the right solution to that but ... I believe you – when you tell me from the Drupal community’s perspective that they solve problems.
Q: Conceptually at least other people definitely argue that if your product is following that standard you know that your thing - you write a wrapper for it, you write it in the same way, you can plug and play and that’s going to be valuable in the same way in terms of efficiency and reliability.
Q: Well, I really think about it in terms of expanding the power of the developer. It used to be ... when I came to Drupal I had to learn not only an entirely new API, but new coding standards, new ways of thinking about fundamentals that I thought I understood from my work with WordPress, with elgg and with other PHP-based CMSs. I see the PSRs as a way out of that. Modern develop shops ... actually the first place we’ve given this talk is in India where lots of developers are asked to learn new languages really quickly. Somebody signs a contract that says, “You’re going to learn this language.” Sure you can figure Drupal, right? If you already know the standards from your work in a previous project it really reduces the [learning] curve, I think.
Q: For us as Drupal developers, learning Drupal 8 means that actually we can go and use anything that uses Symfony components and have a pretty good idea of what’s going on because we’ve got nine of the important ones in Drupal 8. So, this commodity functionality idea I think is a real accelerator. I think developers can benefit from that too.
Q: Why should Drupalists be excited about PHPUnit?
Sebastian: Testing changes your perspective on how you code, on how you work. It solves so many problems, the least of which in my opinion is that you’re sure that the code does what it is supposed to be doing. You get so much valuable feedback while you’re writing a test about the quality of the code itself that you’re testing and you rethink, “I could do this in a different way to reduce the headache that I will have maintaining this code over a longer period of time.”
Q: I wanted to ask for the managers out there. We talked before about the learning curve when you start testing software, that you can expect your developers to take 15% to 30% more time just because they’re learning a new tool.
Sebastian: To put that into context ... Those are studies from by now 10 years ago, some even older than 10 years ago. I think by now, for a lot more developers than 10 years ago, it’s normal to know the tools to some degree already.
Q: Or have used some kind of testing already.
Sebastian: ... have done some kind of automated testing and have heard at least about the fact that you can do things like test first programming, test driven development and so on. So it’s not an entirely alien concept any more when these studies first came out.
Q: You’d be surprised ;-) So we have this rough idea of what the cost is when you get your team into a testing suite. Do we have any idea of what the time savings is like? We’re investing in the future, what’s our return on investment?
Sebastian: So if I remember the numbers correctly from one of those studies, they said that without automated testing embedded into the development process, developers spend somewhere between 40% and 60% of their time on debugging. That goes very close towards zero when you’re doing testing properly. So maybe not entirely down to 0% but somewhere between 5% and 15% maybe. A lot less time spent on debugging. That’s time that you are working on features.
Q: So 40% more productivity.
Testing changes your perspective on how you code, on how you work. It solves so many problems, the least of which in my opinion is that you’re sure that the code does what it is supposed to be doing. You get so much valuable feedback while you’re writing a test about the quality of the code itself that you’re testing and you rethink, “I could do this in a different way to reduce the headache that it will have maintaining this code over a longer period of time.”
- Name: Sebastian Bergmann
- Work affiliation: "I’m a co-founder and principal consultant with the PHP Consulting Company, thePHP.cc. We help companies from small web agencies to Fortune 500 companies make better use of the PHP platform."
- Twitter: @s_bergmann
- GitHub: sebastianbergmann
- LinkedIn: Sebastian Bergmann
- Blog/Website: sebastian-bergmann.de
- FOSS role: Maintainer of PHPUnit
- Current projects: PHPUnit [Wikipedia article on PHPUnit]
- 1st version of PHP: PHP 3
- About: "Hi, I’m Sebastian and it’s 2016 now, so about 15 years ago, I started to work on a tool that is called PHPUnit, which I, at least, back then, never believed and sometimes even today, don’t really believe that it has happened, has become the de-facto standard in the PHP world for doing unit testing, integration testing and all other kinds of testing."