 Why We Refactored JUnit
started 2/7/2003; 10:57:40 AM - last post 2/10/2003; 9:47:17 AM
|
|
Ehud Lamm - Why We Refactored JUnit 
2/7/2003; 10:57:40 AM (reads: 1851, responses: 5)
|
|
| Why We Refactored JUnit |
|
One difference between JUnit and Artima SuiteRunner is that in JUnit, the notion of results reporting is linked to the notion of running test suites. For example, to generate test results as text, you use JUnit's text runner. To generate graphical test results, you use JUnit's Swing runner. By contrast, Artima SuiteRunner separates the notion of running from that of reporting. In Artima SuiteRunner, we provide one runner that can be configured with multiple reporters. Each reporter presents customized test results: for example, a text reporter presents results as text, a graphical reporter presents results graphically.
A nice story about unit testing, JUnit, and test automation.
Not exectly earth shattering, but it has been ages since we had an OOP link here.
I guess the reason for that is that I am not really doing OOP these days, and that the other editors are neglecting their duties...
Posted to OOP by Ehud Lamm on 2/7/03; 10:59:18 AM
|
|
|
|
Neel Krishnaswami - Re: Why We Refactored JUnit
2/7/2003; 2:26:18 PM (reads: 733, responses: 1)
|
|
|
It's probably worth pointing out that this is a complete rewrite, not a refactoring. I think that refactoring might have been the better choice!
|
|
Ehud Lamm - Re: Why We Refactored JUnit
2/7/2003; 2:31:08 PM (reads: 780, responses: 0)
|
|
|
Yep. I should have said as much. When I read this article I searched up and down looking for refactorings..
|
|
Noel Welsh - Re: Why We Refactored JUnit
2/8/2003; 4:01:07 AM (reads: 680, responses: 0)
|
|
|
If we're going to talk about JUnit then I'm going to relate my favourite JUnit story. When I started developing SchemeUnit I just about directly copied the JUnit code. It was really complex and I didn't really understand how it worked. Later, as I learned more FP, I realised that the core of JUnit/SchemeUnit was just:
1. A recursive type Test = TestCase name action | TestSuite name (list-of Test)
2. A fold over said Test type.
Wow! That was it! I love looking at the JUnit cooks tour: http://junit.sourceforge.net/doc/cookstour/cookstour.htm There are so many patterns, so much complexity, just to implement what's a five line program in a functional programming language. Now I don't believe that you couldn't find equivalent examples for FP to OO but its always useful to point out and be aware of the limits of a particular programming paradigm.
|
|
Neel Krishnaswami - Re: Why We Refactored JUnit
2/8/2003; 4:20:15 AM (reads: 681, responses: 0)
|
|
|
That's the same datatype that lies at the heart of my Ocaml test suite! I had a much easier time figuring it out, because I used Kent Beck's paper on Smalltalk testing as my guide. That was small enough that the FP-ification was clear. When I found out about your SchemeUnit paper, I looked it up, and rewrote my test framework, because I liked your assertion language better than mine. It made it easier to turn experiments at the REPL into tests.
Also, I'm not yet fully convinced about test suites making it much easier to change code. A lot of the time, tests have to be written glass-box style in order to ensure you cover all the execution paths, and that means that rewriting a module means rewriting all of the tests too. OTOH, they make finding defects enough easier that I'm sold on them anyway....
|
|
Isaac Gouy - Re: Why We Refactored JUnit
2/10/2003; 9:47:17 AM (reads: 623, responses: 0)
|
|
|
For NUnit 2.0, "the Custom Attributes available in .NET provide a much more straightforward and less ambiguous mechanism" than inheritance.
|
|
|
|