It is my impression that whenever a feature is added, there may be many things
which are
affected by adding that feature. Like if I add a new aspect to the data model.
Then I add
code to save that data. To load that data. Create a form to present that data.
Add some
logic which keys on values of that data. Then you must deal with old saved
models and
update them. Except in some cases the correct update is not clear so a
not-initialized
option is put in place. So cases where this data is accessed now needs to check
for this
condition and properly handle these exceptional cases.
And by not considering those things, you introduce bugs into the software. If
you consider
some of these, but forget others, the program remains broken. TDD helps avoid
bugs by
telling you when the code you changed breaks existing functionality. However, I
don't see
how to avoid breaking the code over new behaviour. I don't see a way to
properly identify
what new behaviour will need to be covered. I want to be sure I'm not
forgetting cases, but
currently I'm overlooking too many of these effects.
It is my impression that whenever a feature is added, there may be many things which are affected by adding that feature. Like if I add a new aspect to the...
... If *all* of your interesting behavior is verified through three levels of tests, programmer tests created in TDD, automated acceptance tests specified by...
... I'm not sure about this. I have some "acceptance" level tests done by myself. I could get testers to develop some of this. What's the key to making sure...
The key to getting functionality fully covered is to apply TDD (aka "Test First") at multiple scales: there's at least two levels of tests written to drive...
... I'm not sure about this. I can test first at the unit level, and at first level integration. After that, the code is integrated and there is no obvious...
... http://www.google.com/search?q=exploratory+testing Exploratory testing is interactive testing by a human tester who is trying to find ways to surface...
Great Reply George. You should copy it to your blog for the rest of the world to see. :-) re: > change here ripples ... This is the "shotgun surgery"...
... Thanks, Keith. I've reworked it a little, and the result is http://blog.gdinwiddie.com/2007/01/18/testing-that-no-errors-remain/ - George -- ... * George...
... Thanks George, that's quite instructive. I'll ponder these things. At the moment though I'm feeling a bit overwhelmed by what appear to be six different...
Alan, it's interesting that you see them as different - to me they all seemed to say the same thing! Slightly different emphasis perhaps, but essentially the...
... You asked for it! Robert Hanson: Use/develop data management frameworks. Your interfaces should be designed such that they force you to fill in all the...
Ha! :-) It just goes to show how much one's memory is blinkered by assumptions. Well, for acceptance testing - do you use a tool? Or is it a human following a...
... I had been using CppUnit for those, and I found it not entirely satisfactory. I now am looking at trying CeeFit and getting a tester into working with...
... Yes, but the suggestions are all pointed in the same direction. The problem, perhaps, is that there are many areas you can improve, but it's difficult to...
Hello, Alan. On Monday, January 15, 2007, at 4:05:37 PM, you ... I don't know about that. But here are some thoughts: If there is some notion like "data" that...
Alan, No enlightenment here, just my thoughts: - customer acceptance tests to show what is missing - unit tests to test the existing code (should preferably be...