Why We Refactored JUnit

I wish... by Anonymous Coward · 2003-01-27 16:10 · Score: 5, Funny

I could refactor my unit.

Re:I wish... by Forgotten · 2003-01-27 16:23 · Score: 5, Funny

You could, if you'd just read your spam before deleting it.
Re:I wish... by Flamerule · 2003-01-27 16:32 · Score: 2, Funny

Hmmm.... You could refactor prime numbers, instead....
Not as sexy, but... oh, fuck it. This post sucks ass.

hrm.... by xao+gypsie · 2003-01-27 16:11 · Score: 5, Funny

why does this sound like something of the beginning of a fantasy story about programming: "in the beginning was Iluvitar, the master of the JU API........then melkor, wishing to expand it...."

xao

--

xao
http://TheHillforum.hopto.org

genericity in testing by Anonymous Coward · 2003-01-27 16:15 · Score: 4, Interesting

One of the biggest problems for a testing framework is fitting all the tests you need in it. Data types such as XML make it really, really difficult.

For example, you have a class that generates an XML document and you want to test it. Which level do you run the tests at? Best to test all levels, of course. How then do you check the accuracy of intermediate results? The answer often is that you can't; the intermediate results are meaningless until you have the complete (or at least almost complete) infrastructure to interpret the data. But once you've run all that, it is very difficult to pinpoint the source of the problem.

I'm glad that Artima SuiteRunner provides a way to handle all of that complexity and write unit tests that are complete but tractable. I just wish it worked with Perl, since I don't use Java anyway.

Re:genericity in testing by Anonymous Coward · 2003-01-27 16:24 · Score: 5, Interesting

Data types such as XML make it really, really difficult.
My big challenges are (1) existing code that wasn't designed for unit testing, (2) testing with databases, (3) testing that involves user interaction and (4) testing that involves multi-tasking. I like unit testing, but it is hard to apply to every task.
Re:genericity in testing by Anonymous Coward · 2003-01-27 18:38 · Score: 5, Insightful

My biggest problem is writing code that works in the first place so that you can even test it ;)
Ah, you do not understand the zen of XP yet. First you write the test. Then you write the code. Then you correct the code so the test passes. The sun is warm; the grass is green.
Re:genericity in testing by thempstead · 2003-01-27 21:16 · Score: 5, Funny

Then you correct the code so the test passes.
nonono ... you correct the test so the code passes ...
Re:genericity in testing by Mike_R · 2003-01-28 00:20 · Score: 3, Informative

Unit testing databases can be simplified by using DBUnit.
With DBUnit, you can describe your database in xml, and each time the tests are run, dbunit creates a new test database starting from the xml files. So you always test on a clean database. Check it out!
Re:genericity in testing by Nyarly · 2003-01-28 02:58 · Score: 2, Insightful

That's extreme programming? Good thing I didn't spend time reading up on this new methodology since I've been doing that for 10+ years.
You'd probably love XP then. A lot of the XP methodologies (with the possible exception of Pair Programming) make heaps of sense, and it's extremely nice to have them all in one tidy package that you can sell to management.

--
IP is just rude.
Is there any torture so subl

The truth about XP by tundog · 2003-01-27 16:20 · Score: 5, Interesting

I find this quite amusing. I recently attended a talk in Montreal given by Kent Beck, one of the X-programming icons. One of the key elements of XP, as I understood his talk, is cutting down what he calls excess 'inventory' which include things such as excess documentation, architecture, etc. By keeping these iventory elements to a minimum, you get quicker feedback, because you have quicker results, which feeds back into the process and allows you to respond quickly to changing requirments.

Well, it also happens that JUnit was developed al la XP by Kent and one other guy (didn't pay attention to who, go look it up!) For a while I was thinking that this XP thing might actually be something, but after skimming through the first 5 chapeters of 'Planning XP' coupled with the statements concerning the JUnit API, I'm starting to think that XP really is just one big hot air balloon.

In his defense though, he did say that refactoring often was a GOOD idea. It's just that he didn't say that you should wait for someone else to do it for you.

My 2 cents.

--
All your base are belong to us!

Re:The truth about XP by Anonymous Coward · 2003-01-27 16:29 · Score: 5, Insightful

I'm surprised, it almost seems like you didn't read much of the information on the website... like you... maybe... just read the slashdot headline and then formed your opinion... because here's what they guy who re-wrote JUnit said:

"at one point I just threw up my hands and said to myself, "Why is this so hard? It would be easier to rewrite JUnit than figure it out."

Just some friendly advice: if you ever find yourself saying it would be easier to rewrite something rather than figure it out, slap yourself. Chances are you are wrong. I certainly was. Creating SuiteRunner was a huge amount of work. Despite my frustrations with JUnit, it would have been orders of magnitude easier to decipher JUnit's source code than to create a brand new testing toolkit."
Re:The truth about XP by mgrant · 2003-01-27 16:46 · Score: 2, Informative

The other guy was Erich Gamma, of Design Patterns fame.
Re:The truth about XP by dubl-u · 2003-01-27 16:53 · Score: 4, Insightful

but after skimming through the first 5 chapeters of 'Planning XP'

If you're a programmer, that's the wrong book to start with. Read Extreme Programming Installed, by Jeffries, et al.

I'm starting to think that XP really is just one big hot air balloon.

In my experience, it's not. Since adopting it a couple years back, my designs are better, my bug counts are much lower, and I am much happier. Feel free to drop me a line if you have questions.
Re:The truth about XP by babbage · 2003-01-27 17:39 · Score: 4, Insightful

On the other hand, there's Fred Brooks' advice from The Mythical Man-Month: "Plan to throw the first one away. You will anyhow."
Sometimes, it really is easier to treat the first one as a prototype of what you'd really like, and then write that second one correctly, from scratch. Witness Mac Classic -> Mac OSX, Win9x -> WinNT, Perl5 -> Perl6, etc.
A lot of these prominent "next-generation" systems may share ideas & even code from their predecessors, but the essential point with each is that they all represent deliberate jump-cuts from the past. Sometimes it really is easier and better to rewrite something, whether or not you fully grok the original.
The real trick is to design systems well enough that, when someone comes along with better ideas, the framework you provide is robust enough to adapt. Mac Classic, Win9x/DOS, and Perl5 are all too inflexible for future use, though at this point each of them is still useful to certain groups. Their successors, however, are all designed with future expandability in mind, so that the "second system curse" can hopefully be avoided. History will tell if it ended up working in any of these cases...

--
DO NOT LEAVE IT IS NOT REAL
Re:The truth about XP by tupps · 2003-01-27 17:49 · Score: 4, Insightful

I think comparing operating systems as a way of throwing out your first born is not correct. Eg MacOS Classic was a direct descendent of the original MacOS that launched in 1984. I am sure that there is very little or no code from the original. Win9X was built on top of DOS which I believe has a lineage older than MacOS classic. Interesting note that both MacOSX and WinNT both came from an external base (NeXT and OS2 sort of). If you want a better example IE 3.0 --> IE 4.0, Microsoft is a classic for working out the problems in the first version or two and then releasing a quality product.

--
Go out and get sailing!
Re:The truth about XP by WaKall · 2003-01-27 19:58 · Score: 3, Insightful

If YOU write the first one, throw it away, and write the second one, then yes, you may be on to something. However, if someone else writes the first one, and you can't understand it/use it, it doesn't that the first solution wasn't good. Maybe the problem lies somewhere else?

You don't learn as much from reading someone else's code as they did from writing it. Don't try mis-quote Brooks to justify not understanding an existing product. Brooks was referring to large-scale team oriented development (like the System 360, or IBM 650 probjects). He wasn't claiming that you should throw out someone else's code because it was the first solution to a problem.

ReactOS by rfmobile · 2003-01-27 16:21 · Score: 2, Informative

They are ... see ReactOS

Intuitive by nettarzan · 2003-01-27 16:30 · Score: 5, Insightful

Is intuitive design necessarily good in programming.?
Recursion is intuitive but not necessarily efficient in terms of performance.
At what point do we decide which is better intuitive design or efficient design.

Re:Intuitive by dangermouse · 2003-01-27 16:42 · Score: 3, Insightful

Recursion is not a design principle, it's an implementation decision-- like choosing between a switch block and cascading if/else blocks.
The author of this article is talking about the JUnit API. An intuitive API is always a good thing.
Re: Intuitive by Black+Parrot · 2003-01-27 16:55 · Score: 5, Funny

> Recursion is intuitive but...

You've obviously never tried to explain recursion to a group of average co-workers.

--
Sheesh, evil *and* a jerk. -- Jade
Re:Intuitive by iabervon · 2003-01-27 17:07 · Score: 2, Insightful

Intuitive deisgn of anything that people will need to change in the future is more important than anything else, because anything you do efficiently but confusingly now will get changed in the future to be broken. If a future programmer can understand your code easily, it can then be optimized if it turns out to be too slow. And good design often turned out to be both efficient and intuitive; it tends to be free of the junk that both makes things confusing and slow.

For that matter, how fast do you want the testing infrastructure to run?
Re:Intuitive by dubl-u · 2003-01-27 17:08 · Score: 4, Insightful

Optimization should never be done until after you've run real-world use cases on code with a profiler. Until then, one should write code that clearly communicates its intent.
"Premature optimization is the root of all evil."
says Knuth, and Martin Fowler says
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
Remember: Computers double in speed every 18 months, but programmers stay just the same. If we want our code to live a long and happy life, then clarity should almost always win over speed.

Origins of XP by Anonymous Coward · 2003-01-27 16:30 · Score: 5, Interesting

I'm sure you've also heard of a guy named Fowler... Martin Fowler is well known in the community for exactly two reasons.

The primary one is his book Refactoring. It describes his experience as a consultant refactoring medium sized software projects, and gives a lot of advice on methods for refactoring.

Apparently Fowler decided that refactoring is a good thing. Not just that, he decided that since refactoring is a good thing, and so should be the basis for programming, since most of the results of programming are bad. By that I mean just that most programs suck, not that they are evil or anything.

At that point he joined forces with Beck and formed his second reason for being well known, XP. As far as I can tell, the philosophy of XP is, "Software usually ends up sucking and in need of refactoring after it has been extended too far. Why wait for it to be extended too far? Just make it suck in the first place and refactor all the time!"

It does have a sort of perverse logic to it, but when I say that XP is bad, I don't just mean that it sucks. As well as sucking, XP really is evil.

Re:Origins of XP by Anonymous Coward · 2003-01-27 16:37 · Score: 5, Insightful

XP is about writing code that can easily be successfully refactored. Total-design-up-front bigots think the code "sucks" because the design wasn't much more general than actually needed at the time, not realizing that making a design at the start of the project that meets the requirements as of the end of the project is almost always impossible, and all the effort in doing so is going to be wasted.
Re:Origins of XP by Anonymous Coward · 2003-01-27 17:26 · Score: 4, Informative

At that point [Fowler] joined forces with Beck and formed his second reason for being well known, XP.

Martin Fowler did not invent XP. It originated in the work of Ward Cunningham and Kent Beck, then was refined by Kent Beck with help from Ron Jeffries and other members of the original XP team. Martin Fowler is an active part of that community, so he co-authored one of the XP books.
Re:Origins of XP by clyde7 · 2003-01-27 20:53 · Score: 3, Funny

I agree. XP is like music in the ears of managers who handle projects and developers which already suck (BTW, Kent Beck is a consultant). XP is not meant to be applied by good developers.

In order to write good (stable, maintainable, extendible, generic, efficient, ...) software efficiently, you want to minimize the overhead (tests, refactoring, redesign, debugging). This can only be achieved by good upfront design skills and applying them as early as possible.

If the code is well written, there's few need
for writing tests (except for sophisticated algorithms), almost no need for refactoring (except for really simple ones like moving/renaming), redesign or debugging.

Unfortunately good OO design is a hard to learn skill and I haven't seen a good book on this yet.
Re:Origins of XP by Ed+Avis · 2003-01-27 22:54 · Score: 4, Insightful

If the code is well written, there's few need
for writing tests (except for sophisticated
algorithms)

Well, duh. If it is well written it won't have bugs, by definition. But how do you find out whether the code is well written, except by thoroughly testing it?

--
-- Ed Avis ed@membled.com

it's all about compatibility by ledbetter · 2003-01-27 16:33 · Score: 4, Informative

Since until now JUnit really was the only game in town for java test-writing, I'm so impressed to see these guys put out something that's still compatible with it!! Even if it was frustration with JUnit that gave them the inspiration. All of us have a bunch of JUnit tests for our code (ok, well SOME of us do), and it's nice to have the option to try out another framework without having to refactor our tests.

Really, in the world of open source, and free software way too little attention is paid to compatibility. Why not be compatible with your "competition"? It's not like you're competing for customers or market share, or any of that crap. We're all on the same team!

--

/. my blog, I dare ya

Read the tests by Anonymous Coward · 2003-01-27 16:33 · Score: 2, Interesting

Well, reading the source is good. But in XP the real "API documentation" are the tests for the system. If you can't understand the tests, you can't understand the program.

Full disclosure: I haven't screwed with the JUnit internals. But I'm working on a system that has over a million lines of code and JUnit 3.7 works just fine for it. Thousands of tests, too.

Re:Good news by jovlinger · 2003-01-27 16:34 · Score: 2

Huh?

*scratches head*

JUnit is unit testing for Java, right? How does the JVM dumping core become the application's fault? How does network IO have ANYTHING to do with unit testing (unless you're testing a network app that is)?

refactor == rewrite? by _|()|\| · 2003-01-27 16:39 · Score: 4, Interesting

I'm the first to admit that I'm not buzz-word compliant, but I was surprised to read the following:

[Artima SuiteRunner] is a design fork not a code fork, because we didn't reuse any JUnit code. We rethought and reworked JUnit's ideas, and wrote Artima SuiteRunner's code from scratch.

I thought refactoring was massaging, even rewriting parts of existing code. So, is Linux a "refactored" Unix?

Re:refactor == rewrite? by dubl-u · 2003-01-27 16:46 · Score: 2, Insightful

Refactoring is improving the design of existing code. So yeah, they're just going for buzzword value here.
Re:refactor == rewrite? by bvenners · 2003-01-27 18:56 · Score: 5, Interesting

I interviewed Martin Fowler, author of Refactoring, last year. In this interview I asked him to define refactoring. He said:
Refactoring is making changes to a body of code in order to improve its internal structure, without changing its external behavior.

We didn't refactor JUnit's code, because we didn't start with JUnit's code and make changes. But we did do what I consider a "refactor" of the design. We started in effect with JUnit's API, and made changes. We started with knowledge of what we liked and didn't like about JUnit's API, and refactored that.
Where you can see the refactoring is not in the code, but in the JavaDoc. Compare JUnit's JavaDoc with SuiteRunner's JavaDoc. I'm guessing it was version 3.7 of JUnit that I had in front of me when I decided I would start over. It may have been 3.6.

free registration required? by smd4985 · 2003-01-27 16:40 · Score: 2, Interesting

i'd like to check out artima suiterunner, but i don't think one should have to register to get access to source. at the very least, we should be able to browse the source online.

don't get me wrong - i'm happy the code is open. we use junit for our open-source product and anything that could help us better utilize junit is much appreciated.

--
smd4985

Re:free registration required? by bvenners · 2003-01-27 18:31 · Score: 2, Informative

It's Larry Rosen's Open Software License (OSL), not ours. I think it is a great license. I liked that they mention trademarks, for example. The main thing I didn't really like about it was the requirement that derivative works also be released under the OSL. I would have been OK with derivative works being proprietary. But I liked the OSL so much, compared to the many other existing open source licenses, that I went with the OSL.
The reason I have people register is to capture email addresses of users. Even though SuiteRunner is free and open source, I consider it a product, and I want to be able to contact users. If you don't want to register, just go to sourceforge and look up the suiterunner project. You can download it there anonymously. Or if you register but don't want to be emailed ever, just uncheck the two newsletter checkboxes.

JUnit does have problems, but .... by shamir_k · 2003-01-27 16:42 · Score: 3, Interesting

I have recently begin to use JUnit and ran into problems right away with the classloading mechanism. If any of you have wierd problems with inheritance relationships breaking, try modifying the excluded.properties file inside the JUnit jar. This worked for me.That said, it would have been nice to be able to modify this without having to unjar anything.
However, I wonder why they rewrote it from scratch. Wouldn't it have been simpler to redesign the problematic parts. And I also find it interesting that they have written their project to be compatible with existing tests. Does that means that JUnit's interface is not problematic, only the implementation? Seems to me like more of a case for JUnit 4.0 then a complete re-write from scratch.
The follow up articles should be interesting

--
more about me

Re:JUnit does have problems, but .... by bvenners · 2003-01-27 18:11 · Score: 3, Interesting

Well, let me clarify. It would have been far easier to figure out JUnit's source code, guess at its API contracts, and integrate my signature test tool with JUnit -- without touching any JUnit code.
However, once I decided to "refactor" JUnit itself, I chose to not use any existing code. My main problem with JUnit was its API, not its implementation.
This is really a generic issue: when do you tweak existing code and when do you start over? By nature I am highly suspicious of urges to start over. In this case, I wanted to redesign the API first and foremost. JUnit's existing code didn't offer much assistance there.
On the other hand, JUnit's API design and very existence offered a huge amount of assistance. We could learn from what we deemed the mistakes in JUnit's design, and replicate what we felt were the good aspects of the design.

Paradigm shift? by HisMother · 2003-01-27 16:58 · Score: 4, Insightful

This is not a troll, but I'm struggling to try to understand why these guys had to work so hard to accomplish what they needed. By their own account, they were driven towards this because they wanted to write API conformance tests -- tests that pass if an API is implemented, regardless of whether it works or not. They wanted, I guess, to see a test pass for each API from the specification that was actually implemented, so they could compute a percentage.

While I can understand what they wanted to do, I guess I don't see why they didn't do this the much easier and (to me, anyway) more obvious way: you write code that uses the API, and if it compiles, then the API is implemented. You write one tiny test class for each API. You have each JUnit test run a compiler over one single class, this proofing each API. This isn't exactly rocket science: you have a directory full of probe-class source code, a single method that tries the compile, and then any number of TestCases that each try to compile one class and pass if they succeed. This is hard?

If you use the unpublished APIs to "javac," you could do this at lightning speed. Alternatively, you could just use a Java parser like the one that comes with ANTLR (since you don't actually need to generate any code) and do it even faster.

--
Cantankerous old coot since 1957.

Re:Paradigm shift? by Osty · 2003-01-27 17:18 · Score: 4, Interesting

And if the methods are there because they have to be to implement an interface, but they return some "Not Yet Implemented" error or exception? How do you handle that with your compiler? I agree with you that they could've accomplished their goal in a much simpler fashion (one test for each API that only fails if NYI is thrown, regardless of any other exceptions or error codes). However, that doesn't mean they shouldn't have re-written the software. They identified issues with extending the existing software, and if they had problems then surely plenty of other people are having problems as well. Assuming that they weren't on a schedule so tight as to prohibit it, they should then do the "right" thing and fix what's broken not only for their current use, but also for their future use and the use of others.
Re:Paradigm shift? by Mithrandir · 2003-01-27 17:58 · Score: 5, Informative

I am a spec writer, I don't play one on TV. I authored the EAI for VRML97 and the various programming APIs for X3D. These are ISO specs, so they come with a lot of weight behind them from the conformance perspective.

As someone who is involved in specification writing of APIs I can tell you that a "compile test" is wholly insufficient for checking class/method signatures. (for this reply, I'm using method as being interchangable for any message passing system - C functions, Java methods, RPC calls whatever)

The first and major problem is not that the methods exist - everyone can cut and paste the spec document - but ensuring that nothing else exists. The bane of every spec writer is the company/individual that decides that they don't like the spec and then proceeds to extend it with their own methods within the same class - often overloading existing method calls. It is these extensions that a spec writer dreads because the (often) clueless end user makes use of them and then wonders WTF their code won't run on another "conformant" implementations of that spec.

Checking signatures is there for one thing and one thing only - making sure the implementors don't embrace and extend the specification in a way that is not permitted by the spec. Creating derived interfaces with new method signatures is fine, adding new method signatures to the specification-defined collection is not. A good conformance test suite will look at everything about the signatures to make sure everything is there, and nothing that should not be is not there.

--
Life is complete only for brief intervals in between toys or projects -- John Dalton
Re:Paradigm shift? by The+Musician · 2003-01-27 18:20 · Score: 5, Insightful

To help answer the grandparent's question: compile != matches API.

Can you write a test-compile program that checks whether the proper public/private/proctected access modifier keywords are set up right on each method? That the method was specified for 'short foo' but the implementor used 'int foo'? Or like Mithrandir said, that no additional methods have been added (such as an overloaded version)?

Basically, compile-compatability is not the same as using the precise APIs in the spec.

This is what I like about Open Source Software by Anonymous Coward · 2003-01-27 17:01 · Score: 4, Insightful

This is one reason I like OSS--when people are not satisfied with currently available solutions, they can take the code and improve it. I have not looked at the new code (and for that matter, am unfamiliar with JUnit), but I think allowing people the freedom to take code and improve it one of the best features of OSS.

Re:This is what I like about Open Source Software by forgoil · 2003-01-27 20:21 · Score: 2

That should be possible for people with unlimited spare time and huge bank accounts. For people with neither of those, or companies that needs to make money to pay their employees so that they can eat next month it is not true either. Having the code doesn't magically make things better.

If I would have the choice between having or not having the source, I would go for having it. I wouldn't do much with it, execpt sending better bug reports, unless I was activly using it for development (as I work as a developer). But this doesn't change the quality of the binaries one bit.

And the time it takes to rewrite a component is only reduced marginally by having the code for the component that failed you. Especially if it is very large. Let's go for some OSS examples.

We've got Apache, and the company using it feels that it is failing them. The performace is just not good enough for them. They have the options to either rewrite, and this will take some quite considerable time, not to mention testing the server, writing plug-ins, etc. If they are not quite big they can't afford one, two, three developers working on this fulltime with no income for them. Developers don't come cheap, not by a longshot.

The other option is to buy/switch to another server. It might be a free alternative (written in the most buzzwordy language of the day) or it might be ISS 6 coupled with Windows Server 2003. Either way it is much cheaper than a rewrite. Rewrites are very expensive.

Open source is a good thing, and it surely can help in debugging and sending bug reports. Let's not get ahead of ourselves and say that it is bad. Many a time I have wanted the full source to windows to be able to find out what the heck is happening to my events, just to bring up one example.

But, and this is a big but, opening the source doesn't make it better. And well written close source software will still be better than a badly written open source one. Just as buying software often is cheaper than building it yourself.

The obvious exception is when software is written without monetary gains ofcourse. Be it that their employers help out, they live of other money (rich, student, won the lottery, begs for food), or similar. But then a big rewrite still costs time, which could have been spent differently.

(But I must confess that I personally think that putting so much time into Mozilla when a rewrite (Konqi) took so much less time, is kind of insane. And any rewrite which makes it easier to develop software is a good timesaver)

I tried too.. by spludge · 2003-01-27 17:03 · Score: 2, Interesting

I also spent many hours deciphering the complicated way that JUnit goes about things so that I could extend it to do what I wanted. In the end it turned out that I could do it (adding a method of timing only certain parts of each test in a generic way) relatively easily but it took many hours of head scratching to understand the framework. JUnit is very flexible, but the code is a bitch to understand :)

Overall though it seems like mostly a documentation issue, not a design issue. Good documentation for the internals of JUnit is pretty non-existent from what I could find. I discovered a lot mostly from examining other JUnit extensions. With some good documentation on JUnit internals and documentation on the internal flow of operations I think I could have hugely cut down on the time I needed to figure out where to plug in. I would be willing to take a crack at this documentation, but I am *definitely* not the best person to do it :) However if anyone else is interested I would be willing to give it a go?

Re:I tried too.. by bvenners · 2003-01-27 18:02 · Score: 4, Informative

I also found that JUnit's documentation was poor, but it wasn't just that. It didn't seem to be designed as a user-friendly API, where the user is a programmer trying to use it as an API. As I wrote in the article, I really liked using JUnit as an application, once I got it going. It was when I went in to integrate my signature test tool with JUnit as an API that I really ran into trouble. The API documentation was very sparse and frustrating. I started looking at the code, which was confusing not just because of poor documentation, but of non-intuitive (to me, anyway) organization.
I was able to figure out what the code itself was doing, but then I was left guessing at what the contracts of the types and the methods were. When you decipher code, you understand one implementation of an interface, not the abstract contract of the interface. I got so mad at it that I opened IntelliJ and started writing my own testing toolkit. I thought it would be fairly easy, but I was wrong. I underestimated how much functionality JUnit actually has in it. And although I think we did come up with a much simpler public API, it took a lot of work to simplify it. So I ended up with more appreciation of all the work that went into JUnit.
I suspect that a lot of JUnit's bulkiness comes from the fact that JUnit started with Java 1.0 or 1.1 and evolved over time in wide-spread public use. Because it was so popular, any design blemishes couldn't be erased in later releases. Eventually enough such blemishes accumlate and it makes sense to start over.
Re:I tried too.. by bvenners · 2003-01-27 19:15 · Score: 2, Informative

A contract for a method in an interface doesn't say what the method does, it draws a fence around the full range of possible things that method could do. So for example, Collection.add method has the contract:
Ensures that this collection contains the specified element.

That leaves room for an implementation class, such as HashSet, to reject objects passed to add that already exist in the set. The Collection.add contract is abstract. It draws a fence around the full range of legal behavior for the add method. HashSet.add is a concrete implementation that is like a single point inside the Collection.add fence.
Imagine stumbling upon the code to HashSet.add without the benefit of the detailed contract-oriented API documentation of Collection.add. You want to implement an implementation of Collection.add in a different way, but all you know is the single point represented by the HashSet implementation. You have to guess where the fence is.
That was the real trouble I had trying to integrate with JUnit as an API. I spent time attempting to decipher the JUnit source code and understood fairly well what it was doing. I made educated guesses at the contracts, but given the non-intuitive (to me) nature of the JUnit API, I wasn't confident in my guesses. I could have integrated my tool and tested it with JUnit 3.6 or 3.7, but had little faith that JUnit 3.8 would not prove my guesses wrong and break my tool.
Re:I tried too.. by Pastis · 2003-01-27 20:00 · Score: 4, Insightful

First, to answer somebody's else comment, the other guy who coded JUnit that nobody can't remember was Erich Gamma. If that name doesn't tell you anything, go back and read some books. It's impressive how the most important people 10 years ago can be forgotten so quickly. Makes you understand why Software is often called Software Craft.

Open source software don't come up often with design documents. This one does. To those who say JUnit is hard to understand, go and read the Cook's tour. Then you'll understand everything. Things have changed a little bit but not that much. Of course if you are not familiar with Design Patterns, I recommend to read Design Patterns first. Yes that's by Erich Gamma and co also called the Gang of 4

I see allready people coming and say design pattern is crap, and that's a proof. But before coming in and complaining, remember the lessons learned by the people who have worked longer than us in this industry. KISS(Keep It Simple...) and don't reinvent the wheel: I am pretty sure that the elegant design used in JUnit could have been refactored quickly to do what those guys wanted without having to rewrite everything from scratch.

The author of this new test suite says it all:

Creating SuiteRunner was a huge amount of work. Despite my frustrations with JUnit, it would have been orders of magnitude easier to decipher JUnit's source code than to create a brand new testing toolkit.

--
Sneak teach kids Algebra using a game

They rewrote the *runners*, not the *framework* by lurp · 2003-01-27 17:08 · Score: 4, Informative

It would be more accurate to say that they rewrote the junit test runners and not the framework itself. JUnit's framework has an extremely simple and clean design, and really doesn't need any changing. The design of the runners, on the other hand really sucks, as Kent Beck has admitted on a couple of occasions.

That said, I don't know if artima has really contributed anything new here. Your IDE likely has a JUnit test runner built into it already (IntelliJ, JBuilder, and NetBeans all do). Ant also already has decent junit test and report targets, which basically include all of the capabilities artima has implemented. Another stand alone test runner is probably not all that useful for day to day development.

Re:They rewrote the *runners*, not the *framework* by bvenners · 2003-01-27 17:48 · Score: 5, Informative

Actually, we rewrote JUnit's basic functionality. You can use SuiteRunner standalone to create and run unit and conformance tests. JUnit is not required.
We made SuiteRunner a JUnit runner as an afterthought, when it dawned on us that no JUnit user would use SuiteRunner unless it added value to their existing JUnit test suites.
One of the things we did originally was make "test" an abstract notion. Reporters can indicate a test is starting, succeeded, failed, or aborted. When it came time to turn SuiteRunner into a JUnit runner, we were able to just report JUnit test results as another kind of test. We felt the ease with which we could turn SuiteRunner into a JUnit runner was a validation of our abstract test notion.

if it ain't broke.... by the-build-chicken · 2003-01-27 17:40 · Score: 2, Insightful

and also, I don't have to put my email in the database of a company that may or may not honour their privacy policy when times get tough, when I download junit. Maybe I'm a little jaded about open source sites that look flashy and require emails to download...burnt by the whole 'jive' from coolservlets.com fiasco (making lot's of cash are you now boys...remember, you can't buy back your dignity). The simple concepts are often the best, junit works great. I see no real advantage in this one.

Re:if it ain't broke.... by bvenners · 2003-01-27 22:52 · Score: 3, Informative

As I mentioned elsewhere in this topic, I ask for registration so that I know who the users are. Even though SuiteRunner is free and open source, I consider it a product. If you check the Artima Newsletter checkbox, you'll be notified of updates to SuiteRunner as well as new articles on Artima.com.
Also, for several reasons we decided to create a web-based discussion forum for SuiteRunner user support rather than using a mailing list. The web forum (I fear this will add weight to your conspiracy theory, but the forum is based on Jive.) requires that you have an account, so by getting an account when you download SuiteRunner, you are ready to post to the SuiteRunner users forum.
On top of that, shouldn't I get points for requiring such a minute amount of information to register? Many times I have been confronted with a long scrolling page full of edit boxes I'm required to fill in. At Artima.com, all I ask for is a name, which you can fake, a nickname, which you can make up, and an email address that I confirm. The name and nickname shows up on forum posts. If you watch a forum topic you get notified by email when someone posts a reply, which is why I confirm the email address even if you opt out of the newsletter.
Interesting that you found the site "flashy." I was going for simple. If you look carefully, you'll see the site is primarily text with a bare minimum of graphics.
Nevertheless, although I incorporated Artima Software a couple years ago, it is still just one person (me). So what you really need to ask yourself is not whether you trust a faceless corporation with your email address, but whether you trust me with it. I assure you I am very concerned about privacy.

Design first, or refactor? Re:Origins of XP by 2nesser · 2003-01-27 18:02 · Score: 5, Insightful

making a design at the start of the project that meets the requirements as of the end of the project is almost always impossible

I believe that this quote is true for commercial software. The word processors, email clients and web browsers in the world should not be designed at the beginning of a project. The cost of doing that far outweighs the benifits. But...

When you are designing life critical applications (fly-by-wire, ABS, pacemaker, cancer radiation machine...etc) it is not acceptable to be redesigning while coding.

If you cannot model the way a system must react at all times, under any input, then what makes you think that your software should be responsible for someones life.

More and more software is being designed for life critical applications. If XP is being used to develop them, I'm worried. You cannot stumble onto 100% correct software. In a large system it takes a lot of money - an exponential curve, the last 3 bugs will likely take more money than the first 100 - time and a good design.

Re:Design first, or refactor? Re:Origins of XP by chromatic · 2003-01-27 18:24 · Score: 4, Informative

In a large system it takes a lot of money - an exponential curve, the last 3 bugs will likely take more money than the first 100 - time and a good design.

That assumes that the rate of the cost of change rises over time. XP rejects that assumption, and the XP practices are designed to keep the rate of the cost of change consistent.

--
how to invest, a novice's guide
Re:Design first, or refactor? Re:Origins of XP by 2nesser · 2003-01-28 02:52 · Score: 2, Interesting

Here is an honest question, I know very little about XP, but how does it keep the rate of change consistent with all this "refactoring" going on?

As your code base increases from cycle to cycle and more features are added to the system do you not end up spending most of your time "refactoring" your old code so that the new feature fits into the system?
Re:Design first, or refactor? Re:Origins of XP by chromatic · 2003-01-28 05:05 · Score: 2, Informative

That's a good question. Several of the other XP practices work in your favor in that case.

First, if you've been doing the simplest thing that could possibly work, your code is already pretty simple -- it doesn't have superfluous stuff to work around. Second, if you're testing continually, you have a safety net to notify you if you accidentally break the essential behavior. Third, if you've been refactoring continually, the code will be decoupled and much easier to change. Aggressive testing helps this too. Finally, if you're using the planning game to work on half-day features, you're dealing with manageable chunks of code that very rarely touch more than a couple of individual units.

There are times when you have to schedule a couple of days for larger refactorings, but they're not common. If you have intelligent developers who keep up the good practices, the code ends up really clean, really easy to extend, and surprisingly well-designed.

--
how to invest, a novice's guide

What's the big deal? by melted · 2003-01-27 18:17 · Score: 3, Interesting

Our QA people have developed their own framework for running tests in C#. It automatically discovers test cases via Reflection API, allows to group them into suites, run suites, generate reports, debug. It took 2 people 1.5 months to write it (while also dogfooding it to themselves and writing actual tests). No big fanfare, no buzzwords.

"Refactoring" - holy fuck, where do you get such words?
*

Solid Foundation For Software Refactoring by Bart+Du+Bois · 2003-01-27 21:19 · Score: 3, Insightful

To get to know refactoring, I can refer to http://www.refactoring.com (by Martin Fowler).

For those interested in the value of refactoring (whether it's merely a buzzword), I can refer to a research project of ours, at http://win-www.uia.ac.be/u/lore/refactoringProject

By the way: since the article does not go into behaviour-preserving restructuring of JUnit, they shouldn't mention 'refactoring' in the title.

Yet another JUnit like tool. by M.M.M. · 2003-01-27 23:21 · Score: 3, Informative

I have another one,
it is geared towards tests with multithreaded environment.

here is the project page
http://www.michaelmoser.org/jmtunit/

The library sets up a thread pool (n threads) and runs a number of identical test sequences; each test sequence is a virtual user (m users). All threads are waiting on one input queue for test requests. The threading modell is the same as in most of the popular application servers

The programming interface is very similar to JUnit - there is a JMTUnit.TestCase with some additions, there is JMTUnit.TestResult.
The tool does print out performance statistics

Test-Driven Development by PinglePongle · 2003-01-28 01:45 · Score: 2, Informative

Kent Beck - co-author of JUnit - recently published "Test-Driven Development", a book about how you can change your coding habits by creating the tests up front.

One of the most useful sections is a complete walk-through of the creation of unit-testing tool for Python - it's probably the best way of understanding the internals of the JUnit framework without trying to reconstruct every single line of code...

--
It's all very well in practice, but it will never work in theory.

60 of 192 comments (clear)