Re: RE: Tool to create assertions from a running Java application

Teemu KanstrĂ©n <[email protected]> Mon, 3 Feb 2014 19:58:51 -0500
Newsgroups gmane.comp.java.junit.user
Message-ID <CAGagL=dHGTRQeNM_iY5MVXWhhY7jp3U27bA8LB93L0Rctm7kRA@mail.gmail.com>
On 3 February 2014 07:57, Stephen Connolly
<[email protected]>wrote:

>
>
> Quality tests are about meaningful test names and small test case size
> with at most 1-2 asserts per test case.
>
>
Nice ideal. In practice having a good coverage with at least somehow
meaningful tests would be often a good start.. Just saying.

The end effect of that tooling is that the entire code base is frozen in
> place, as any change results in a complete cascade of test failures... and
> you run off analysing each and every one just to determine whether the
> change is the intended effect and the test needs updating, or whether the
> test is right and you broke something you shouldn't have.
>

I think you just made a great usecase for implementation based test
generators. Re-generate after each change and show off your 100% coverage.
Even if the tests are pointless, manager is happy :)


> automated tooling will not produce quality test cases (unless they are
> processing an independently derived specification... in which case who
> tests the specification to be correct... Quis custodiet ipsos custodes?)
>
>
This is how techniques like model-based testing work. In my view your
"independently derived specification" is in such case tested by the
implementation. Because your implementation is from the viewpoint of your
tests another "independently derived specification". When you generate
tests and run those, they will tell you if there is a mismatch. Which of
your interpretation of system intent is at fault is then to be
investigated..

-Teemu