From: Dossy <do...@pa...> - 2002-04-09 19:19:29
|
On 2002.04.09, Kent Beck <ken...@cs...> wrote: > Here's my thinking. The tests are actually not quite at the right place. By > making the tests on TestResult, you are presupposing that TestResult is the > right place to put the functionality you want. (In law they call this > "leading the witness".) I'll go along with this. You are right, though, I am suggesting that TestResult _is_ the right place to get test result information. Otherwise, the class is misnamed, or I don't understand what the words "test result" really mean to you. > What I'm more interested in is what behavior you as a JUnit user would like > to see. For example, can you write a textui.TestRunner test that displays > the output you would like to see when a test doesn't finish? I'm attaching a patch that adds a test to TextRunnerTest.java. Please look at it and provide feedback. (I don't think the functionaliy I'm asking for is UI-specific, though. I'd like to be able to get at the information regardless of what UI is running the tests.) > I'm sorry if this seems like the stone game ("Bring me a test. No, put it > over there. No, ..."), but the discussion of where to test is a design > discussion for me. I still think the right place to test is on TestResult, as that's where the behavior needs to be. I need to be able to make TestCases that make assertions about the number of tests that were started, the number of tests that completed, the number of those which resulted in failure, and error. From that, I can compute the number which resulted in success. Specifically, this is useful to me coupled with a bunch of changes I've made to JUnitPerf that computes average time per test case when running a non-waiting timed load test. > We are all (Erich and I most of all) trying to figure out how to have an > open source project where design and implementation responsibility are > aligned. I'm sure it's frustrating for you all, as it is for us. I'm still not certain why the "make it work then make it better" cycle that involves testing, coding and refactoring isn't a suitable way of doing this. Are you (and Erich, and the rest) afraid that JUnit can't be evolved? Are you afraid that it might get to a state where it cannot be saved, or that the cost of change will increase? -- Dossy -- Dossy Shiobara mail: do...@pa... Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) |