In our company, we are only two IT staffs, and I'm the only developper. I'm developping rich intranet applications using plain php and extjs as javascript framework.

Our development cycle is usually very fast, such that often people are using tomorrow what I develop today. This is possible through an automated build script.

Now the problem:

It happens, that despite all the care, things break. And myself or the end users will notice it once the application update is published. Of course a testing framework (or mabe two, one for php and one for js) would be the solution. But this looks to me just as an unsurmountable barrier, because of these points:

  • I never used a testing framework, and lack necessary knowledge
  • A testing framework puts constraints on the way code is written (and I cannot judge for now, if my code fits any particular framework). I therefore fear that I had to refactor my code to be able to use a testing framework.
  • I fear that writing the tests is likely to take more time than to write the code.
  • Much of the code depends on the data present in different databases. How to make up mock data that can be used for testing.

Can someone give me advice on how to introduce a testing framework in a setting where proficiency and time are scarce ? I know this question is really broad, but I hope I will get nonetheless some precious advices.


It took me several months before I dared to dive into Unit testing, and it took me just one hour to get up und testing. It will take me some hours more to include this permanently into the build process.

I really feared too much !!

Unit testing is not more work (or just slightly more) than testing with echo's and var_dump's. The advantage is that it is permanent. Once you change some code, and the test still works your done. There's no need any more to retest manually.

  • 1
    I think you are two steps ahead of yourself. First you need to determine what kind of tests need to be performed and what the best strategies are for executing those tests. Test frameworks only rear their head when the decision has been made to perform (fully) automated tests. Commented Mar 13, 2014 at 10:19
  • Forget about this project. Do you want to learn how to write tests or not?
    – JeffO
    Commented Mar 13, 2014 at 19:49
  • @jeffo I'm ready to learn it. So why give you the advice to forget about it ? Because unit testing is for large projects with many developpers ? Because it's overkill in my situation ? Explain your reasons in an answer please. Commented Mar 14, 2014 at 5:53
  • 1
    Congratulations, Lorenz, on overcoming your fears & jumping right in. make sure to tun automated regression tests before each commit to version control or release to the customer. And, every time you find a bug, fix it and add a test that would have caught it.
    – Mawg
    Commented Dec 3, 2014 at 15:36
  • @mawg Thank you. Yes, it is my intention to include the testing in the build script, such that the build will be interrupted if a test fails. Commented Dec 4, 2014 at 12:02

1 Answer 1


I agree that the question is broad, but I'd consider it borderline answerable. So here's my take.

  • Doing something for the first time takes longer than doing a well-known thing, but for a professional, time to improve your efficiently in a lasting way is almost always worthwhile. It shouldn't take more than a day to pick up enough of a testing framework to automate some of the things you need, and that will probably pay for itself sooner rather than later.
  • Testing frameworks can impose restrictions on your code structure, but usually they go out of their way to minimize that. The conditions they do make are usually things that are a good idea for healthy, maintainable code anyway (small functions, single responsibility, orthogonality, etc.)
  • Spending more time on tests than on production code can happen - in fact, some people claim this is the normal and expected way of programming - but that is not what you should be measuring. The value to optimize is total turnaround time on the requested features at an acceptable quality; the fact that test automation tools have many satisfied, even enthusiastic users is at least mild evidence that this can be pulled off.
  • This is least easily answerable without context. The general trend of opinion is that anything which interacts with a database isn't a unit test, but an integration test. Testing code that is coupled to databases poses a problem with several kinds of solutions: invent your own primitive mock database; take advantage of mock databases offered by testing frameworks; switch use an in-memory database or just put one on a really fast drive, etc.
  • 1
    It shouldn't take more than a day When it really would take only one day to set up the framework and to run one unit test, this would be great. The second unit test would take just an hour and all the others just the time to write the test code... Commented Mar 13, 2014 at 10:47
  • 1
    @LorenzMeyer: if you have doubts, I recommend this video vimeo.com/10569751 - will take just 50 minutes to look, rest of the day should be time enough to download a framework and write your first tests.
    – Doc Brown
    Commented Mar 13, 2014 at 11:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.