لطفا منتظر باشید ...
Testing in the Extreme
There's a school of thought that says that software functionality that can't be checked via automated tests doesn't exist.[8] I'm afraid I have to disagree with this. There are functional aspects of software design that are difficult if not impossible to test, especially with automated tests. One, in particular, is the aspect of extensibility. How do you check extensibility with an automated test? You really can't, and yet you have to design and code for extensibility just as you would any other feature. Another is maintainability. Surely we coders want to write maintainable code, and surely we'd consider code that was too tangled to maintain to be buggy from a design standpoint, yet we might not know this until after the software ships and we begin to try to support it. The code would survive automated tests, but it would still be buggy. My point is this: automated testing presents a baseline by which you can determine basic software health, but it is not the final word. Just as your annual physical exam can miss detecting a number of health problems, automated tests provide only a basic check. They do not ensure program correctness, nor can they even identify every feature in a software package. Some elements, such as extensibility and maintainability, are beyond the scope of automated tests but need to be there nonetheless. Testing can't detect everything that might be wrong with software, and therefore can't detect everything that might be right. Software functionality can exist that automated tests could never detect, but that you rely on to extend and maintain the system. This is particularly true of design elements that make the system easier to work on.
[8] Ibid. Page 45.
Beyond being a tool in your toolbox, testing also brings with it certain responsibilities. Once you take on the onus of writing test methods for your work, you have to write them all and keep them up-to-date. You can't simply write one test method, never update it, and declare your code tested. When you implement a test method, developers who look at your work down the road (including you) have the right to expect the method to do what its name implies: Test its class completely. Anything less is a bug, and hurts more than it helps.
Note that as you gain more experience writing tests, you'll be more able to judge when a test is or isn't necessary. This is rather subjective, and you have to be careful. Once you start looking for tests to eliminate, schedule pressures can coerce you into believing that a critical test isn't really needed. Weed out tests only when you're absolutely sure, and never base these decisions on scheduling concerns. Default to testing too much. If you're going to have a flaw as a developer, this is a good one to have.
