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

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

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 | Find similar | Unroll thread

Thread

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

csiph-web