Thank you Buck; a convincing, straight-forward, explanation of life in the swamp,
and how TDD can help me work.
-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Wednesday, March 27, 2013 12:10 PM
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] Convert to /Free
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
--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/wdsci-l.
midrange.com
