Path: csiph.com!news.bbs.geek.nz!.POSTED.agency.bbs.geek.nz!not-for-mail From: Kiwi User (Kiwi User) Newsgroups: comp.lang.java.programmer Subject: Re: Calling deprecated methods Date: Sat, 16 Dec 2017 09:08:28 +1200 Organization: fsxNet Usenet Gateway | bbs.geek.nz/#fsxNet Message-ID: <1782037676@f38.n261.z1.binkp.net> References: <40184664@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="4415"; 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: Richard Damon Xref: csiph.com comp.lang.java.programmer:37856 On Fri, 15 Dec 2017 22:31:59 -0500, Richard Damon wrote: > On 12/13/17 12:30 AM, Kiwi User (Kiwi User) wrote: >>> I know nothing of this sort of testing though I am curious to know how >>> you'd find the data that would generate errors when a method accepts a >>> number and handles 1, 1.5, and 2 just fine but 1.6 returns an >>> incorrect result. >>> >> Traditionally, you'd read the design specification. The one thing you >> MUST NOT do is to look at the code while you're writing tests. You're >> trying to test that it does what the requirements say it should and not >> what the coder wrote because he may have misunderstood the spec. > I should have extended this to say that testers should read javadocs output but not the actual source code. > One major exception to this, is that the people who write the code > should report to the testers any algorithmic breakpoints that are not > implied by the specifications. > There's a bit more they should do as well: this needs to be reflected back to the designers and added into the system documentation. It also needs to be clearly documented in the code, e.g. in Java it needs to be mentioned in class and/or method-level comments so that it is visible in javadocs output. > For instance, the size of the data being > processed my affect which method is used to reach the goal. The test > suite needs to make sure it exercises every case. Testing likely would > test the smallest and largest, but if there is distinct middle case, it > might be missed, and tests near the break points might be called for > too. IOW prefer to see this sort of thing described at both the documentation that designers working on system changes and enhancements will read *and* where it should be seen and read by devs making changes to the code. -- Martin | martin at Gregorie | gregorie | dot org