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

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

Re: Calling deprecated methods

Show all headers | View raw

On Wed, 13 Dec 2017 04:51:52 -0800, Eric Douglas wrote:

> Interaction is sometimes the hard part of testing.  Method A works fine,
> unless you've called Method B with value C then Method D with value E
> first?

My test system can handle any or all of that stuff, but doesn't even 
attempt to do GUI testing because I don't have a good solution for that.

My main test harness is set up to do low level tests on a class but could 
be easily extended to do more. Its main loop reads a test script, which 
is a text file whose general format is

command param1 param2 param3... # comment

and, as each line is read:
- the line is printed, preceded by a line number
- comments (a '#' and everything to its right are removed
- split the remainder into 'words' on whitespace
- the first word is treated as a command, typically a method name
  the other words are treated as parameters and stored as an 
  array of Strings and a parallel array of ints (result of
  applying Integer.parseInt('word') to every parameter in the line
- call the doTest(command, p, n) method of the class-specific test
  harness (see below) where p is the array of String parameters and
  n is the array of int parameters,

The class specific test harness is merely a monster 

   if (command.equals("commandname") then
   {
      result = class.command(paramlist);
      print("Result: " + result);
   }
   else
   if 
   ....
   else
      error("Unknown command:" + command);

structure in the doTest() method. The param list is a correctly ordered 
list of specific elements in the p and n arrays.

Because the class that is the class-specific test harness contains next 
to nothing apart from the if.then.else ladder, its fast and easy to write 
and maintain. 

Sometimes its convenient to put class-specific test helper methods in the 
class specific script, but I've seldom found that to be necessary except 
when method or constructor parameters are not ints or Strings.

Its constructor is passed references to print() and error() which are 
defined in the test harness, so its convenient to declare all class-
specific test harnesses as subclasses of a superclass. 

Common helper methods, such as one to convert T/F, Y/N, 1/0 strings into 
a boolean value are defined in the superclass.
 
The class under test is generally created by using a command line that 
passes the constructor arguments.

As I said: simple and flexible. Because each input line is listed the 
output looks something like this:

1: # test10.txt - Initial test for myclass
2:
3: myclass name 23   # Create myclass with parameters "name" and 23
4: 
5: #test toString
6: toString          # "name is 23" expected
7: Result: name is 23
8:
9: No errors expected

No errors in test10.txt   

The test harness counts calls to error() and outputs the error count at 
the end of the run. I usually put the script's ID as the first line in 
the script and a comment about the expected error count as the last line. 

The script determines the order in which methods are executed and so its 
easy to test both correct and incorrect ordering of method calls.

The output is sent to 'out', so its easy to scan through the test 
results, which are generally fairly easy to read if you are careful with
formatting multiline results, i.e. indent them so they start under the 
first character of the initial line and wrap overlong lines. 

Regression testing is simple: just capture the results of a good test and 
save it. After a regression test, compare the output with the saved 
results. I user 'diff' for this: a good regression test produced no 
output while a bad test shows all the differences.


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

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