On 3/27/2013 11:35 AM, Gary Thompson wrote:
much appreciated, and maybe TDD is off-topic ??? but better testing
seems good - it's the "full test suite" that has me stumped.
My main project now is feeding data to a robotic pick system.
Current phase is "partial production" meaning we feed selected
customer orders to the robot and if results are ok, we ship,
if not, we re-stock.
Maybe the key is "full test suite" means, for example, you do not
model the picking robot, you just cover basic module function to
ensure that all required output data is present and in the correct
format ?
Don't start with thinking about the entire system. Start thinking about
an individual function. The idea is to have a test that exercises every
input/output you want that function to do.
Once you have full test suites for all your functions, you have a
de-facto test suite for the whole system. In theory. I can't speak for
anyone else, but I don't have a full list of the functions in my system
- heck, many of my business rules are locked away in mainline code, not
even subroutines, never mind sub-procedures. I'm not going to be able
to build up a full test suite in my lifetime for the existing code base.
On the other hand, for new sub-procedures and for changes to simple
sub-procedures, I try very hard to get my test suite going. This gives
me a huge amount of confidence that I did not break anything in the
function during the course of my working on it. Couple TDD with the
awesome undo/redo power of RDp and I find myself trying several
different ideas out before I settle on the final one that will go into
production.
Aside from the problem of no tests for existing code, TDD suffers from
another problem that is not at all easy to get around: the database.
Much of my code is database driven. A customer can have two dozen
status codes, for instance. I can write a test for each status code
that I know about, but what happens when the business adds a new status
code? I have a code path that isn't tested.
But the larger issue is that I don't generally have many functions which
operate without the database. This means I need to set up a test
database that I can use which will exercise all the edge cases -
situations that may not exist in my actual production database. Trying
to account for all the kooky things a web user can do with a browser is
an eye opening experience, and one that TDD has helped me with - a lot.
It's better to know my weaknesses than to imagine I don't have any, and
TDD does that in spades.
--buck
midrange.com
