Path: csiph.com!news.bbs.geek.nz!.POSTED.agency.bbs.geek.nz!not-for-mail From: Kiwi User (Kiwi User) Newsgroups: comp.lang.java.programmer Subject: Re: Calling deprecated methods Date: Wed, 13 Dec 2017 17:30:42 +1200 Organization: fsxNet Usenet Gateway | bbs.geek.nz/#fsxNet Message-ID: <280508399@f38.n261.z1.binkp.net> References: <644722387@f38.n261.z1.binkp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: news.bbs.geek.nz; posting-host="M6YmRdZYyc42DJk0lNlt/X4dpP4dzvceBNabSmESN3E"; logging-data="1013"; mail-complaints-to="abuse@news.bbs.geek.nz" User-Agent: VSoup v1.2.9.47Beta [95/NT] X-MailConverter: SoupGate-Win32 v1.05 X-Comment-To: Eric Douglas Xref: csiph.com comp.lang.java.programmer:37852 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