Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37855 > unrolled thread

Re: Calling deprecated methods

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#37855 — Re: Calling deprecated methods

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.

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. 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.

[toc] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#37857

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web