From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30141 invoked by alias); 9 Jan 2003 09:45:52 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30131 invoked from network); 9 Jan 2003 09:45:44 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (217.128.22.71) by 209.249.29.67 with SMTP; 9 Jan 2003 09:45:44 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id E7187D34AE; Thu, 9 Jan 2003 13:45:29 +0400 (RET) Date: Thu, 09 Jan 2003 09:45:00 -0000 From: Joel Brobecker To: David Carlton Cc: Michael Elizabeth Chastain , ezannoni@redhat.com, fnasser@redhat.com, gdb@sources.redhat.com, jimb@redhat.com Subject: Re: [rfc] plans for linespec.c Message-ID: <20030109094529.GO7129@gnat.com> References: <200301090424.h094O8224303@duracef.shout.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2003-01/txt/msg00122.txt.bz2 > There's actually an interesting question here as to whether or not I > even can design coverage tests for the original version of > decode_line_1: my only understanding of the function comes from > decomposing it, so any tests that I'd design would be compromised by > the assumption that I've preserved the behavior by that > decomposition. Though, obviously, I'd be in a good position for > designing coverage tests for the newer version. In my very modest experience - former engineer for the Canadian Automated Air Traffic System (CAATS) project -, this is not a problem. If you can create a set of tests that provide a good coverage of your code, then your tests will be very helpful later on in any case because they will allow you to verify that a modification does not introduce any change in behavior. Any change can then be investigated. Even if one of your test is wrong because there was a bug in the code that twisted your understanding of what the function should do, the test will one day "regress" when you fix the bug in the code. That day, the regression will be investigated and the test will be corrected. Eventually, you'll get close to 100% correct base of tests... Most of the time on CAATS, the author of a given piece of code was also given the task of doing the "unit testing", which includes writing enough test drivers to exercice as much code as possible. These unit test drivers proved to be invaluable. Hard to maintain sometimes (the software quality was not always the same as in the CAATS code itself, sigh), but very very very valuable, even today now that the project has been delivered. Especially today I'd like to say, for the CAATS team has lost a lot of its talents. -- Joel