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