First class developer: who ?
in [Java Help]
|
Prev: Speaking of thread safety?
Next: solutions manual to A First Course In Probability 7th Edition by Sheldon M. Ross
From: Martin Gregorie on 14 Mar 2010 08:06 On Sat, 13 Mar 2010 22:04:32 -0700, BGB / cr88192 wrote: > often, if there is no good way to test or use a piece of code, well then > this is a bit of an issue... > If its not testable, how do you find out if it does *anything* correctly? IMO, an essential part of the design is making it testable. That should have equal priority with usability, adequate error and incident reporting and a way to measure performance. All are essential to developing a good application. I seldom use a debugger, preferring to use the trace log approach to debugging & testing. I make sure the tracing and its detail levels are easily controlled and invariably leave this code in the product. The performance hit is almost undetectable when its turned off and the payoff from being able to turn it on during a production run is huge. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Patricia Shanahan on 14 Mar 2010 10:13 BGB / cr88192 wrote: .... > often, if there is no good way to test or use a piece of code, well then > this is a bit of an issue... The conditions that trigger a piece of code in operation may be difficult to cause in system test, but the code itself can be unit tested. I find it helps to write unit tests and detailed specification, usually Javadoc comments, in parallel. Sometimes a small change in an interface that does not harm code I'm going to write using it makes the implementing classes much easier to test. Patricia
From: BGB / cr88192 on 14 Mar 2010 12:00 "Martin Gregorie" <martin(a)address-in-sig.invalid> wrote in message news:hnijg6$8ik$1(a)localhost.localdomain... > On Sat, 13 Mar 2010 22:04:32 -0700, BGB / cr88192 wrote: > >> often, if there is no good way to test or use a piece of code, well then >> this is a bit of an issue... >> > If its not testable, how do you find out if it does *anything* correctly? > yep. that is the issue... this comes up in cases where the data needed to test the code can't be easily generated or simulated, which means it could only be adequately tested once the other code which provides its data exists. often, I have noted that in these situations, the code to produce such data would itself be non-trivial, ... so, as noted, it is a bit of an issue. the end result is that one often finds that the end result of such an effort is often not terribly useful anyways... as an odd feature of reality, most things which tend to be useful also tend to be easy to test. this is also a big part of why I stay away from "AI" and similar fields, as it is a large space where it is neither clear how to implement, much less how to test, most of this stuff... > IMO, an essential part of the design is making it testable. That should > have equal priority with usability, adequate error and incident reporting > and a way to measure performance. All are essential to developing a good > application. I seldom use a debugger, preferring to use the trace log > approach to debugging & testing. I make sure the tracing and its detail > levels are easily controlled and invariably leave this code in the > product. The performance hit is almost undetectable when its turned off > and the payoff from being able to turn it on during a production run is > huge. > I use a debugger some amount, usually to identify where a problem has occured and the situation at the place it has occured.
From: BGB / cr88192 on 14 Mar 2010 12:56 "Patricia Shanahan" <pats(a)acm.org> wrote in message news:mfednb9OEK-RcgHWnZ2dnUVZ_hednZ2d(a)earthlink.com... > BGB / cr88192 wrote: > ... >> often, if there is no good way to test or use a piece of code, well then >> this is a bit of an issue... > > The conditions that trigger a piece of code in operation may be > difficult to cause in system test, but the code itself can be unit tested. > > I find it helps to write unit tests and detailed specification, usually > Javadoc comments, in parallel. Sometimes a small change in an interface > that does not harm code I'm going to write using it makes the > implementing classes much easier to test. > well, I am thinking in language-neutral terms here (because I write code in several languages). for example, my compiler/VM project currently involves ASM, C, C++, and Java, all in use at the same time (and, this set may extend). (this is, in addition to several smaller/special-purpose mini-languages). a lot also depends on the size and complexity of the "unit" to be tested... the main issue is with larger pieces of code (say, 50-100 kloc or more) which need in general difficult-to-produce test data. an example of this would be a compiler-codegen (converting from some IL into ASM, for example), which can prove difficult to test on its own. in this case, one will need typically a compiler frontend, as well as some amount of code to be run through it, to produce the IL to effectively test the codegen. even then, one may end up spending years finding and fixing all of the little bugs which either escaped notice before or which got introduced as a result of later activity, ... sometimes, may also end up with code which is subject to "system effects", where many of the parts will play together in a way which is unexpected, and so one has to test that the entire system works well (rather than being able to test all the individual parts and determine that "the whole" will work by extension). or, in cases where a minor issue in one place will go and cause something to misbehave elsewhere, ... these particular sorts of situations can prove difficult to unit-test... however, a partial answer I have used here, and I tend to stick to, is to try to split things into "layers", where each layer produces data which can be manually examined, and where often the input for each layer can be written by hand if needed. for example, my assembler accepts textual ASM, my codegen accepts textual IL and produces textual output (ASM), internal signatures, serialized metadata, .... is also textual. I have ended up preferring textual data as it makes things much easier to examine and write by hand, even in many cases where it is not necessarily optimal (vs a binary or direct-API-call interface). however, a lot of these notations also tend to be character-based, rather than token-based. I will not claim originality here, and in fact the notation for my type-signature system, which is one of the more notable examples of this usage, had been influenced some by the signatures used within the JVM, but, also, a lot by the IA64 C++ ABI, which is used by GCC and friends, and as well has a few things in common with MS technologies (although MS uses binary signatures and a different metadata layout). .... however, there are many other things which are much harder to test, but I have also found that things which are particularly hard to test are also often similarly difficult to find a use for. more often, anymore, I will write down the idea for things like this, and implement them if/when a need to them may appear (which will often at the same time provide the test-cases). or such...
From: Martin Gregorie on 14 Mar 2010 13:03
On Sun, 14 Mar 2010 09:00:47 -0700, BGB / cr88192 wrote: > "Martin Gregorie" <martin(a)address-in-sig.invalid> wrote in message >> IMO, an essential part of the design is making it testable. That should >> have equal priority with usability, adequate error and incident >> reporting and a way to measure performance. All are essential to >> developing a good application. I seldom use a debugger, preferring to >> use the trace log approach to debugging & testing. I make sure the >> tracing and its detail levels are easily controlled and invariably >> leave this code in the product. The performance hit is almost >> undetectable when its turned off and the payoff from being able to turn >> it on during a production run is huge. >> >> > I use a debugger some amount, usually to identify where a problem has > occured and the situation at the place it has occured. > I've usually found debuggers to be the slower option in terms of programmer time. Tracing statements that show data as well as location are a better way of tracking down the problem - especially when the causative code is some distance from the apparent trouble spot. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |