Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been doing website programming for 15 years and PHP for the last 5 years or so. I've always written solid code. HOWEVER, I have a client that is insisting on 80% of the code being unit tested. Since the client is ALWAYS RIGHT, I am planning on using PHP_CodeSniffer to make sure my code looks right and PHPUnit to do my unit testing. I'm hoping to learn something through this experience.

Are these the right tools to use? How much time is involved in setting up PHPUnit and writing the additional code? It should take me around 8 weeks to write the webpages and self-test as I have done in the past. If I add 4 days additional (10%) for unit testing (PHPUnit), is that enough? Thoughts? Suggestions? Thanks.

share|improve this question

migrated from stackoverflow.com Mar 22 '11 at 1:08

This question came from our site for professional and enthusiast programmers.

1  
unit testing can double development time. –  Dagon Mar 21 '11 at 20:42
    
You worked with PHP 2.0 ? Nice! My input doesn't qualify for an answer so in short: For the choice of tools you are right on imho. See my take on php testing frameworks and for phpcs i don't even know any alternative. For the time to add: After doing TDD for some time I'm usually slower without it but as i started out certain things too waaay longer (+50%). If you use a framework that makes testing hard (lots of static stuff) add even more. –  edorian Mar 21 '11 at 23:43
1  
It will increase the initial up front development, but over an 8 week project, you will find it makes less difference as the unit tests will help you to discover bugs earlier and easier. –  Steve Fenton Sep 4 '11 at 21:11
1  
@Dragon, kinda, but unit testing also speeds up development [there is a lot less of the deploy/test/find\fix cycles –  monksy Oct 5 '11 at 14:28

4 Answers 4

In one line: it depends how you work. I honesly think that 10% is way too little. It should be at least 25%, if not 40%, if not 60%, if not more.

First, I very much agree with your client there. Unit tests are an essential part of a robust, easy to maintain, easy to debug product.

I'll speak from what I know. I use TDD (Test-Driven Development) for most projects. TDD basically make you write the tests before the actual code. They establish a set of acceptance criterias that the end product needs to meet. Usually, you will spend from 50% to 70% of your time writing tests, and the remainder to implement code to make them pass.

While it may sound absurd and/or enormous, I can assure you that it isn't. Here's why:

  • You will be able to figure out what are the best architectural pattern(s) to use while writing the tests. This way, when you start coding, the application architecture will change minimally (because we all know how costy it is to redo an application architecture).
  • You code only to make the tests pass (therefore making the end product acceptable). You will not spend time programming useless/out-of-scope features.
  • By having less code (i.e.: only code that you actually need), it is less error-prone. (Less code = less errors).
  • If you make a mistake, and you will, it will take a lot less time to figure out why there's a problem, and where the problem is. If the tests are written properly, it means that a single mistake will cause a single failure, not a chain reaction. This way you can easily pinpoint the source of the problem in a matter of minutes, if not seconds.
  • It will take a lot less time to implement the actual code with unit tests. As soon as a test fail, you know that something is wrong. You don't have to do back-and-forth with the client to fix bugs.
  • You will eventually have to do back-and-forth with the client to fix bugs, because nothing can catch 100% of errors. However, you can easily catch 95% if not more.

PHPUnit is pretty much the de facto tool for unit testing PHP, and it's very good at that. I haven't used PHP_CodeSniffer much. However, I think that if you are working alone, you probably don't need it. It's more useful in a team to make sure the code looks the same no matter who coded it.

share|improve this answer

Props to you for having the attitude that you will learn something from this experience. I'm sure you will.

The very first thing you should learn is that the necessity of unit testing has nothing to do with how experienced you are. The best developer is going to be one of the best unit-testers, as well:

Bill Venners: You say in your book Refactoring: "If you want to refactor, the essential precondition is having solid tests." Does that mean if you don't have tests you shouldn't refactor?

Martin Fowler: You should think of it as walking a tightrope without a net. If you are good at walking a tightrope, and it's not that high up, then you might try it. But if you've never walked a tightrope before, and it's over Niagara Falls, you probably want a good net.

From http://www.artima.com/intv/refactorP.html

I used to write PHP with no unit testing. Then, after years of practicing unit testing in Java, I found that I could not work on anything much more complicated than single pages in PHP without unit testing. The reason? Productivity. Without unit testing, I could not refactor with confidence — this meant that either A) I would have to tear much more down and work over everything from the beginning again, or B), I'd have to deal with ugly, legacy code.

When you are making a bid do you need to factor in time to test? Yes. Does it seem intuitive that that will take more time? Yes, again. You will probably, as some other answers have roughly estimated, need to estimate 50-100% greater than without unit tests.

However!...

  • You will catch and address specification holes earlier
  • Which means you'll be developing to a cleaner and more solid specification
  • You'll be able to respond quickly and confidently to spec changes
  • You will have fewer bugs
  • Your bugs will be caught sooner and easier to fix

And as a result, your estimates will be more accurate. If you charge hourly, you will impress your clients more and be able to raise your rates. If you charge flat-rate, you will make more money per hour.

Without testing, your estimates are most likely a crapshoot. Bugs, change-orders, and redefinitions are all terrible for estimating accurately. Testing is the the key to minimizing the impact of all three!

share|improve this answer

There is not an easy answer as to how much longer it will take you.

But as a ground rule, if its a short project: I'd say that development together with good unit testing will take 1.75-2 times as long as development without unit testing. For longer projects maybe 25-30%?

I suggest making unit tests before you write your code. Taken in this way, building the unit test scaffolding actually becomes a part of your design process, and so you shouldn't consider that you are losing time to unit testing, but rather that the building of the unit test is helping you to design a great product and the existence of that test after you've built it makes it easier for you to ensure that it remains that way. Having to write unit tests firsts is wonderful in helping to focus on real requirements, gives us a clear way to test whether we are done (passing unit tests) and helps us to "test early and test often".

As for PHPUnit.... It's been a while since I used it, my impression is it is powerful but perhaps needing some more work before it is really polished.

If there's one thing I want to communicate here, though: Please don't see Unit Testing as a mere formality at the end of your project. If that's all it is, in my opinion, it is worthless.

share|improve this answer

The answers so far are quite thorough so I'll just add one point not covered: the extra time due to using PHPUnit will be

  1. higher at first since you're learning it, and
  2. lower the non-test development time as you gain confidence with it.

Unit testing model classes that don't deal with presentation are pretty straight-forward. You write a test for each class, and in those test cases you can directly instantiate and configure an object for testing a particular method/feature. Once you have PHPUnit setup and running, you'll be able to get these tests working quickly.

Unit testing web pages can be more tricky. If you use Zend Framework, Symfony, Smarty or any other MVC engine, getting PHPUnit to play nicely with them can take more time. We use Zend Framework and I spent a considerable amount of time building base classes for testing controllers and view scripts in isolation. Given the size of this project, you're probably better off starting with ControllerTestCase.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.