Drupal, meet PHP FIG and PHPUnit - with Sebastian Bergmann, 1 of 2 [video]

0
PHPUnit and PHP FIG logos

Listen to the podcast:

Download podcast (36.1 MB)

Part 1 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. Now we're releasing those to you!

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.

“Hi. I’m Sebastian Bergmann. About 15 years ago I created PHPUnit to help PHP developers build better software. I would like to congratulate the Drupal community on the release of Drupal 8. As far as I know PHPUnit played some role in it.” :-)

Q: You discovered PHP in 1997 or 1998, why did you stick with it for the last 18 years?

Sebastian: I like the language. I like the very pragmatic approach to solving the web problem, which does not mean that I’m happy with everything that is in PHP. There are some things in PHP that I don’t think should be in PHP. There are some things missing that I think should be in there. Some things have been implemented in a way that I wouldn’t have done it, wouldn’t have done that way if I were the only one to decide but I can see the compromise was necessary for the greater good, but all in all, I’m very happy with PHP.

Q: What is PHPUnit? How can I benefit from it?

Sebastian: PHPUnit is a so-called unit testing framework that’s stands in the tradition of the XUnit family of testing frameworks that began a really, really long time ago. So, it’s a unit testing framework or at least that’s how PHPUnit started. It’s used for so much more than just unit testing these days. The unit test helps you test one unit of code in isolation from all collaborating objects. So, for instance, you have one method of a class and you want to test this known input that you get the expected output. That’s the smallest kind of test that you can do. You can do all kinds of other tests in a much larger scope. One of the biggest, one of the most important things in testing software is finding the smallest scope in which you can test what you want to verify and the smallest thing that you can test and the smallest scope that you can test in is the unit test scope.

If you make it larger then you come to integration tests when you, for instance, test that one piece of code interacts correctly with another system, be it a web service or a database or whathaveyou. The largest thing that you can test in an automated way would be to test the entire application as a whole, which in the case of a web application it usually means, if you take a real HTTP client, send them real HTTP requests to a real HTTP server, get it to real HTTP response back and inspect that. That you can also do with PHPUnit.

Q: What does a PHPUnit bring for Drupal developers? What do they get out of your collaboration with Drupal?

Sebastian: Hopefully, better code, hopefully less bugs and hopefully fun.

Q: Fun?

Sebastian: Yes, it’s hard to believe and when I started working on PHPUnit and got interested in testing, I really couldn’t believe it, but it turns out there are many, many people out there, many developers for whom testing is a lot of fun. It brings, to some ... it has this feeling of being destructive in a constructive way ... like trying to find ways to break their code and writing that down in the form of tests and then they’re really happy when they see, “Okay. I cannot think of any other way to break this code and everything is fine. Everything is green so I’m having a good feeling that this code is correct, is robust and there's this nice synergy between when it’s easy to test a piece of code that means that the code is well-written, well-crafted, so in the future when your requirements change or you get new requirements, then, it will be easy and convenient and not a horrific experience to adapt the code to the new requirements.

"There's this nice synergy: when it’s easy to test a piece of code that means that the code is well-written and well-crafted. So in the future when your requirements change or you get new requirements, then, it will be easy and convenient and not a horrific experience to adapt the code to the new requirements.

Sebastian: What I could describe is very a common experience when you as a developer starts using the tool for testing. PHPUnit is, by no means, the only testing tool in the PHP community, just the one that is used the most. And contrary to what some people believe, I’m not an angry German that does all those bad changes in PHPUnit to hurt them intentionally :-D But it’s common that whatever testing tool you start using, you will not have fun with it at first if your code is not testable. Many people curse at the testing tool and say, “Oh, this is stupid.” That’s okay but it’s not the real issue. It’s just that the testing tool makes it obvious that the code you’re trying to test is not as well-crafted as it could be. You feel this pain and that pain hopefully makes you reconsider the way that you have written your code and you start making changes to make the pain go away.

Q: Do you have any pro tips for people who are trying to learn how to write a good testable code?

Sebastian: Writing tests first helps a lot of people, but over the years I’ve met plenty of people that said that they cannot think like that and that’s also okay. If I were to give a rule for that, then, it would be, “Don’t commit code to your version control without a test.” That’s a very pragmatic way of thinking about it, so by the time you share the code with the rest of the team, the tests are there and the rest of the team doesn’t care about whether or not you have written the test first or the code, but having to have the tests by the time you commit means that the code is testable.

“Don’t commit code to your version control without a test.”

Guest dossier

  • 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."

Add comment

By submitting this form, you accept the Mollom privacy policy.