Path: csiph.com!news.bbs.geek.nz!.POSTED.agency.bbs.geek.nz!not-for-mail
From: Kiwi User <martin@mydomain.invalid> (Kiwi User)
Newsgroups: comp.lang.java.programmer
Subject: Re: Calling deprecated methods
Date: Tue, 12 Dec 2017 22:41:06 +1200
Organization: fsxNet Usenet Gateway | bbs.geek.nz/#fsxNet
Message-ID: <3801429685@f38.n261.z1.binkp.net>
References: <2163157443@f38.n261.z1.binkp.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: news.bbs.geek.nz; posting-host="M6YmRdZYyc42DJk0lNlt/X4dpP4dzvceBNabSmESN3E"; logging-data="1013"; mail-complaints-to="abuse@news.bbs.geek.nz"
User-Agent: VSoup v1.2.9.47Beta [95/NT]
X-MailConverter: SoupGate-Win32 v1.05
X-Comment-To: Eric Douglas
Xref: csiph.com comp.lang.java.programmer:37845

On Tue, 12 Dec 2017 13:33:06 -0800, Eric Douglas wrote:

> I currently work for a small business, so not a lot of time to waste
> writing tests that can guarantee every enhancement won't break any
> existing code much less comment blocks, when we have a dozen big
> enhancement requests and 2 developers.
>
If a class is largely getters and setters and its other methods for linear
things, then you're right.

However, if there are ANY edge cases and/or errors to be handled, then just
writing it and incorporating calls for in in the application code is likely to
bite your bum because (a) unit/system test of the combined code module may
never exercise all its edge cases due to inadequate test data and (c) once a
user starts trying something the system designer never thought of and generates
 the edge case, it may take a lot of time and effort merely to determine what
happened and which module crashed.

Using a test harness will probably save time and effort overall because: such
harnesses are typically very fast to write: once you've got a test harness
skeleton running, the code needed to interface it to a new class is almost a
script and the incremental code within that which tests a method is 2-4 lines
plus the actual method call. Last but not least, its dead easy to set up test
date that can deal with all normal and abnormal inputs AND contains (comments)
to show whether each method test in the script should succeed or fail and what
the expected results should be.

On top of that, once you have a set of tests set up, they tend to be fast and
easy to run, so its practical, and worthwhile to rerun them after and change is
 made to the class. I have sets of 30-50 regression tests that execute in under
 a second and will, if done properly, inadvertant mistakes made when you're in
a hurry.

Been there, done that, got the benefits.


--
Martin    | martin at
Gregorie  | gregorie
          | dot org