Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #37857
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Calling deprecated methods |
| Date | 2017-12-16 16:24 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <p142u0$a4f$1@dont-email.me> (permalink) |
| References | <40184664@f38.n261.z1.binkp.net> <1782037676@f38.n261.z1.binkp.net> |
On 12/15/2017 4:08 PM, Kiwi User (Kiwi User) wrote:
> 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.
Is there a place for coverage analysis in this scheme of things?
--
esosman@comcast-dot-net.invalid
Eleven hundred thirty-one days to go.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: Calling deprecated methods Richard Damon <Richard@Damon-Family.org> (Richard Damon) - 2017-12-15 22:31 +1200
Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> (Kiwi User) - 2017-12-16 09:08 +1200
Re: Calling deprecated methods Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-12-16 16:24 -0500
csiph-web