a‡Y The easiest way to add unit test to your application
Unit testing shouldn't be hard. In fact, given its usefulness, it should be easy and pleasant-a tool that every developer would never want to do without.
And yet, I see programmers (and, more frighteningly, systems architects) struggling with it constantly. In many cases, they are saddled with large codebases that have never seen any tests whatsoever on one hand, and the fact that a recent changes has caused their entire system to crap out on the other.
The unfortunate thing is that most a€oexpertsa€¯ will tell you that you need to drop everything you're doing right now and spend however long it takes to build a complete testing harness for your project.
These people, in my oh-so-humble opinion, live in a fairy-tale land in which deadlines are things that happen to other people and management is made entirely of sugar cookies.
Back in the real world, stopping development for weeks while you figure out how to add unit tests to cover your entire codebase is simply something that cannot be done (at least, not if you want to keep your job), no matter what future benefits it might bring.
The good news is, adding unit testing to your existing project only takes five minutes-which is pretty much how long it takes to get a unit testing framework installed. That's it. Move on.
A test today is better than a thousand tests tomorrow
Still here? OK, read on.
Chances are that your application a€omostly worksa€¯ today. If it didn't, you'd have much bigger problems to worry about than unit tests. Adding unit tests is not going to solve any problem because you don't have any.
That's fine; you just need to look at testing in a different light.
Where unit testing helps is in managing change. The job of unit testing is not to determine that your application works as advertised: that's what your QA process-of which unit testing is part-is for.
Rather, unit testing is there to help you ensure that changes you introduce in your code do not have consequences that you did not intend.
Once you make this decision, adding unit tests becomes really easy-and very productive.
A typical example is correcting a deficiency in your code. Obviously, you can't fix a bug until you've reproduced it. And, when you have figured out a way to consistently trigger the bug, you'll have to do so multiple times as you try to figure out a solution to the underlying problem.
Curiously, that exactly one of the things that a unit test does well. Instead of triggering the bug manually, you can simply write a test that does so programmatically; in so doing, not only have you added a very important test to your code-you actually made reproducing the bug (something that you will probably need to do multiple times as you fix it) much easier.
Another place where writing unit tests is an easy part of the development process is refactoring existing code. The worst thing that can happen here is that a change you make breaks something else, and you don't find that out until the code is in production. That, as they say, would be bad.
Since that's something you (a) want to avoid and, therefore, (b) you will have to track anyway, writing a unit test is a great way to automate the process. More interestingly, it's an easy way to write a meaningful test that validates how your application works as opposed to what your code does (more about that later).
Adding new functionality
This leaves with the scenario in which you're writing completely new code1.
I know I will probably catch a lot of flak for this, but here's my recommendation: do absolutely nothing.
Writing code is often a process of near-scientific discovery. The abject failure of the waterfall model should have taught us by now that the idea development and architecture are two completely separate phases is simply at odds with reality.
In the real world, we have to contend with imperfect specifications, unknown constraints, and the distinct possibility that, halfway through the development process, we find out out that we're trying to solve the wrong problem.
As a result, I, personally, prefer to write code in an almost free-flowing manner, focusing on finding the best solution to the problem at hand. Throwing t
Truncated by Planet PHP, read more at the original (another 6606 bytes)