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

Groups > comp.lang.java.programmer > #37852

Re: Calling deprecated methods

Show all headers | View raw

On Wed, 13 Dec 2017 07:57:40 -0800, Eric Douglas 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.

Ideally the tests would be written by somebody who wasn't involved in writing
the code and in any case NOT the code's author, but that is not always possible
 and you often ending writing tests for your own code. When this happens its
always best if you can write the tests first and then code later. Next best is
if you can write the tests after you've written and compiled a skeletal class,
i.e. one with all constructors and public methods defined but with no code
inside any of them: the one exception is a compilable 'return' statement in
methods non void methods.

I usually do inductive tests, i.e. if its meant to work correctly for positive
ints over the range 1 - 999, does it work for 5,6 and 7, what about -1,0,1
(should object to -1 and 0, 1 should be OK), and do the same for 998, 999 and
1000 (first two should be OK, last flagged as out of range).

You need a set of tests that can drive the code through all its expected paths,
 i.e. no errors expected and, if a method being tested is type void then you
should immediately follow its call with getters that can show that it did what
was expected. Conversely, you need to check that any method that is expected to
 valid input and/or detect logic errors can successfully do so and, if error
messages are generated, that they correctly describe the error and are
understandable by whoever will be expected to read and act on them.

You'll probably get frustrated while writing the first few test sets, but once
you're up to speed with what the tests are meant to do and have developed
something of a tester's mindset it should get easier and more intuitive to do.

> Surely GUI is worse as the human variable is bigger, and the client
> machine is a new variable.
>
the major problems are how to script the various mouse clicks and keypresses
and get them into the GUI and to do the reverse process of capturing the
resulting GUI changes and saving them for automated comparisons during
regression testing.

There is already a class-level, non-GUI unit test harness, JUnit, but it wasn't
 clear that it could do regression testing. I've seen it used and wasn't all
that impressed: the output looked, to me anyway, like an over bulky and
unscannable format and, as I said, it wasn't clear that it was good for
regression testing.

There may be some testing package that allows you to automate GUI tests and
regressin tests, but I haven't seen or heard of one.

> It may be possible to crash an API only if a
> user clicks too fast, or clicks on something while pressing a key at the
> same time, or other such unexpected activity.  I had one crash we could
> only reproduce with a specific video driver.  Sometimes the ability to
> crash is relative to the speed of the mouse clicking and the speed of
> the CPU or GPU.
>
Yes, I understand.

I tend to use the sort of scripted test harness I've described for any code
that is going to end up in a library (I use the same approach for both C and
Java) and for complex code that's nested deeply enough in an application to
make fine control of its inputs difficult.

As a compliment to the unit test harnesses that we've been talking about, I
install quite voluminous diagnostic tracing in applications and especially GUI
apps. My tracing class supports and is used to provide hierarchic tracing
levels, i.e.

Level   What it shows

0       Tracing is off

1       exit from functions/methods formatted as
           result = methodName(parameter values)

2       level 1 plus method entry as
           methodName(parameter values) [entered]

3       anything worth tracing inside a method

My tracing system also has a circular buffering option. If this is used trace
messages are stored in a circular buffer rather then written to err and the
buffer is dumped if a fatal error (signalled by calling the diagnostic system's
 error() method) which writes the buffer contents to err in arrival sequence,
outputs the error message and stops the program.

This is very useful for diagnosing randomly occurring, rare errors in long
running programs because it can show you what led up to the error exit. The
buffer size is configurable.

Since the cost, during normal live operation, of testing an integer debugging
level and then skipping over the diagnostic output is negligible in comparison
with the rest of the program's normal operations while the benefit of being
able to turn on tracing when problems occur in live code is large, I strongly
advocate using well structured diagnostics during development and leaving the
diagnostics in place whenthe code goes live.

I usually use a -d command-line option to turn debugging on. Its repeated to
get more detail, i.e. -dd for trace level 2. Buffering is typically controlled
by a -b=999 option where 999 is the buffer size in diagnostic lines stored, but
 you do need a good command line parser to do this. Java didn't provide one
back in version JSE 3 days, so I wrote my own somewhat before I wrote my
diagnostic system. Both were based on stuff I'd previously written in C.


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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> (Kiwi User) - 2017-12-12 16:31 +1200
  Re: Calling deprecated methods Eric Douglas <e.d.programmer@gmail.com> (Eric Douglas) - 2017-12-12 10:24 +1200
    Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> (Kiwi User) - 2017-12-12 20:05 +1200
      Re: Calling deprecated methods Eric Sosman <esosman@comcast-dot-net.invalid> (Eric Sosman) - 2017-12-12 15:41 +1200
        Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> (Kiwi User) - 2017-12-12 21:04 +1200
          Re: Calling deprecated methods Eric Douglas <e.d.programmer@gmail.com> (Eric Douglas) - 2017-12-12 13:33 +1200
            Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> (Kiwi User) - 2017-12-12 22:41 +1200
              Re: Calling deprecated methods Eric Sosman <esosman@comcast-dot-net.invalid> (Eric Sosman) - 2017-12-12 17:57 +1200
                Re: Calling deprecated methods Eric Douglas <e.d.programmer@gmail.com> (Eric Douglas) - 2017-12-13 04:51 +1200
                Re: Calling deprecated methods Eric Sosman <esosman@comcast-dot-net.invalid> (Eric Sosman) - 2017-12-13 08:21 +1200
                Re: Calling deprecated methods Eric Douglas <e.d.programmer@gmail.com> (Eric Douglas) - 2017-12-13 05:40 +1200
                Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> (Kiwi User) - 2017-12-13 15:19 +1200
                Re: Calling deprecated methods Eric Douglas <e.d.programmer@gmail.com> (Eric Douglas) - 2017-12-13 07:57 +1200
                Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> (Kiwi User) - 2017-12-13 17:30 +1200
                Re: Calling deprecated methods Richard Damon <Richard@Damon-Family.org> - 2017-12-15 22:31 -0500
                Re: Calling deprecated methods Kiwi User <martin@mydomain.invalid> - 2017-12-16 09:08 +0000

csiph-web