|
|
|
| Authored by: Anonymous on Tuesday, May 15 2012 @ 08:30 AM EDT |
My take on the 7 test files are that test files are never
intended to ship... they exist for an entirely different
reason.
In my development work, we can spend as much time on writing
test classes as on the "real" classes.
Their job is then NOT to add functionality to your
development effort - but to help prove the quality of it, to
prove that the "real" code meets its requirements. And,
probably more importantly, to show that it continues to meet
its requirements as changes are made in the future - changes
to both code and requirements.
In my most recent project, just running through all the
automatic regression tests would keep my computer busy for 2
hours. If a test failed after I'd made a change, it would
either mean that I'd done the change in an incompatible way
(breaking the requirements) or I needed to update the test
to fit in with the requirements.
All the code that executes those tests is not shipped onto
the runtime platform, but I view it as a *vital* part of the
development - vital to the quality of the shipped product.
It was certainly vital to being accepted, and
me being paid!
If you view the 7 test files in that light, you can
understand that they help prove the correct functioning of a
different class (or classes) - which *is* (are) shipped.
So, while not shipped, and not contributing to the
functionality directly, they do contribute to the quality of
what is shipped.
Would Android have been successful if it was poorly
implemented? If not, then the testing process most certainly
contributed.
How you quantify it is difficult...[ Reply to This | Parent | # ]
|
|
|
|
|
