Answering your questions about unit testing

Thanks to everyone that joined our Unit testing for project managers webinar yesterday. It was great to see so many people engaged and asking questions. I’ve pulled together answers for your questions we didn’t get to on the webcast. If you have more questions, leave a comment below!

If you missed the webinar or want to re-watch it, the on-demand version is now available.  The slides are also posted on Slideshare.

Your questions answered

I’ve started hearing about property-based testing. Have you ever used it and, if so, would you recommend it? One library is Eris, which seems to be a port to PHP of QuickCheck (from Scala, I believe).
I’ve never used property-based testing but it does seem to be interesting. There are a few resources you can look at.

How would one start unit testing in the middle of project? Is it even possible or recommended?
Carefully. :) Seriously, if you are going to do this, stop development. Don’t try to continue development and backfill tests. Some assumptions about the application will have to change in order for it to be testable.

  • Stop
  • Train
  • Pick your toolset
  • Write your first test
  • Modify the app if needed to be able to test
  • Loop until all critical code is covered

Remember, only test that code that is yours. Don’t try to test APIs you call or your underlying framework.

How do you start unit testing on a system that is already fairly large? It seems like it would take a year or more of work to try to implement unit testing for a system like that?
Boil the frog slowly. Don’t try to do it all at once. A great book to read before you start is Modernizing Legacy Code. It will help you get a handle on what is necessary to modernize your application so that it can be tested.

I find it to be difficult to write unit tests up front as you often have to set up and prepare objects to be able to test their outputs. Do you have the same experience and how did you tackle this problem?
Yes. I am an old-school ‘seat of the pants’ coder. I think in code. So writing tests first does not come natural to me. However, I have found that thinking things through in tests is not difficult once you make the switch. The way I have done it in the past is to sit down and write out all the tests I need to cover the behaviors I want my application to have. Not complete tests, just method names. Once I have the method names, I can be fleshing out my tests. testCreateMessage is going to have to have a message object. Guess, what, I now know I need to build a message object, I go to my Model directory and create an empty class called Message. Then I repeat the process until I have all my tests fleshed out. At this point, I know not only the objects I need but what they need to do and how they will interact.

What about having another set of tests that actually pull in live data from Twitter?
That’s not unit testing, that is either integration testing or acceptance testing. Those are both very important, but beyond the scope of the discussion.

Is it right to constantly modify tests or deprecate some altogether as the project functionality changes?
It would be wrong not to. As your application changes, your tests need to as well. If you remove functionality from an application (e.g. have you noticed that modern word processors don’t have a ‘Save’ button anymore?) there is no need to keep testing for that functionality. Some tests – like things testing bug fixes – need to stay so that the bug doesn’t reappear later on. Your tests are not carved in stone any more than your application is.

Why don’t you have the time or the luxury to do unit tests if it leads to faster development?
I do. Right now, all of the code I write is for my own projects. Since I understand that unit tests speed development, I start them very early in the process these days. The problem is non-developer managers who see unit tests as just more overhead for developers.

Just wanted to say it feels like the talk title was a little bit misleading when the only thing to managers was “do it”.
The point of the talk was to justify the “just do it” at the end. For unit testing to pay dividends, managers – the target audience for the talk – have to understand why they are necessary and what is involved. That was what I was trying to convey. Many managers – especially those who have never been developers – have a hard time understanding that spending more time up front will pay huge dividends on the back end. It is easy to understand why since a lot of development projects never get finished but get canceled. If you want to improve your chances of not getting canceled, and of producing higher quality software, then yes, just do it. Train your developers, give them permission to write unit tests. Get out of their way.

The following two tabs change content below.
    Cal Evans is the technical manager for Zend training and certification at Rogue Wave Software. For the past 10 years Cal has worked with PHP and MySQL on Linux OSX, and when necessary, Windows. He has built on a variety of projects ranging in size from simple web pages to multi-million dollar web applications.

    About Cal Evans

    Cal Evans is the technical manager for Zend training and certification at Rogue Wave Software. For the past 10 years Cal has worked with PHP and MySQL on Linux OSX, and when necessary, Windows. He has built on a variety of projects ranging in size from simple web pages to multi-million dollar web applications.

    • http://kahelamp.wordpress.com/ Agi

      Awesome discussion, it was very informative and inspirational. Thanks Cal!