Re: unchecked conversion warning.
Martin Gregorie wrote:
Roedy Green wrote:
Perhaps docs should be written by the folks who write the test code.
The get to ask the coders, decide what makes sense. They will than
answer the questions that need answering and clarify that which is
guaranteed.
Ideally the javadocs would form at least part of the module-level
documentation and so should be written by the designers, not the coders.
I think there's a case for the module design documentation to be written
entirely as a javadoc package suite, i.e. they contain the descriptive
text as class and public method level comments as well as the associated
declarations. There's also a case for compiling, as a sanity check, them
before they are given to the coders.
Further, the design team are the people who should specify the module and
regression tests and (hopefully) should be writing them too.
IME you really don't want coders writing module tests. The problem is
that they will tend to write tests for what they coded rather than for
what the specification asked them to write and they may skimp on corner
cases and error handling.
"Can't we all just get along?"
The business world speaks of "siloing" - "to silo" is to isolate personnel to
a narrow wedge of the overall project.
Siloing can be good, but in software development usually is not.
It's vanishingly unlikely to be good if it isn't done on purpose with full
understanding of its effects.
Siloing is not the same as division of responsibility. One can divide
responsibilities among a team who is generally, and to varying degrees
specifically aware of various dimensions of the project.
Siloing would be to keep programmers entirely away from test writing.
There is more than one type of test. Loosely, tests fall into unit tests and
everything else.
Unit tests are, as the name should indicate, aimed at rather minimal units of
code. They verify the behavior of a type's public face. Positively and negatively.
For example, from the spec for 'List#get(int)' it follows directly that the
argument might be negative, zero, or positive, and may equal, exceed or be
less than the size of the list. Any programmer worth their salt had better be
able to write a full suite of unit tests for such a method.
<http://docs.oracle.com/javase/7/docs/api/java/util/List.html#get(int)>
As the designer of a type, let's say 'Foo', with a method 'goof(Bar)', the
programmer knows exactly how the method should handle various possible values
of the 'Bar' argument. Ideally up front, whilst writing the Javadocs thereto.
From the Javadocs the tests follow directly. It shall do thus and so with a
'null' argument, and react in a certain way to a reference to an uninitialized
instance, and another to one in an inconsistent state, and yet another to one
in a valid, initialized state.
That part is unit testing. Unit tests operate on components in isolation,
separated from the context of a larger application. Their sources and sinks
(inputs and outputs) are simulated via mock objects and other tricks where
absolutely necessary. This form of testing is also called "hermetic", meaning
sealed away from the operational environment.
The rest goes by different names according to specific line of inquiry. Some
suggest "functional" test for everything regarding how components function /in
situ/, while others restrict it to just those that confirm behaviors'
conformance to spec /in situ/. That narrower sense is also called "acceptance"
testing or "regression" testing. (Note: I'm being a little loosey-goosey here.
If you have more refined definitions by all means share them.) Tests to ensure
that components function well with each other are "integration" tests. Tests
for performance and throughput or stability or load are called "performance",
or in that last case, "load" tests.
Unit tests
Everything else (Functional tests in the wide sense)
- Acceptance / regression (functional in the narrow sense)
- Integration
- Performance
- - Load
Your taxonomy may vary. It will cover pretty much the same range, though.
Cross that in a matrix with a second dimension of techniques: programmed
tests, fixtured tests (those with deterministic setup conditions),
simulations, random-event tests, parametrized probabilistic test scenarios,
and so on.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg