Slashdot Mirror
An Early Look at JUnit 4
An anonymous reader writes "Elliotte Harold, proclaimed 'obsessive code tester', took an early look at JUnit4 and shows how to best utilize the framework in your own projects. Many feel that this is one of the most important third-party Java libraries ever developed. It promises to simplify testing by exploiting Java 5's annotation feature to identify tests rather than relying on subclassing, reflection, and naming conventions."
Maybe I am the only one that understands this too... J-J-J... J UNIT!
After reading this, I noticed it was great but the most obvious omission is a GUI test runner. Fortunately, it is possible that if you want to see a comforting green bar when your tests pass or an anxiety-inducing red bar when they fail. you'll need an IDE with integrated JUnit support such as Eclipse. Neither the Swing nor the AWT test runners will be updated or bundled with JUnit 4.
+1 funny, -2 overrated. Life isn't fair.
Those are the legion of programmers who learned, certified, and bluffed their way into Java experience. Junit or not--it's going to be very tough landing a job.
Transcend Humanity. Please.
...with JUnit 3, they have to go and improve it. I'll be eating my heart out for a while, because my company will surely not go to Java 5 before Java 6 is out, so these mentioned features will not be available to me. And when they are, I'll have to change my modus operandi.
Actually: Nice work, guys. I'll probably appreciate this once I get a chance to use it and wrap my head around it.
When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
It would be nice if they synchronized the version numbers so that it was obvious which version of JUnit worked with which version of Java.
I'm looking at the samples and am left scratching my head. I don't see any difference in the various example tests they show. Maybe someone can explain this "annotation" and how it is better (it's certainly more verbose!) than the normal way of doing things.
Jesus saved me from my past. He can save you as well.
Just kidding, JUnit, one with capital U.
The Holy Grail of test automation is Automated Test Generation, in other words the ability to have your application record inputs and outputs in a way that can be easily played back or transformed into a test. Pro/Engineer has this capability. Are there other applications that can do that?
Test 1 2 3 4
For those who haven't heard of him, Elliotte Rusty Harold is a big name in the Java world - he maintains a very popular blog/news site and has written a slew of excellent books.
He's also a committer on the open source Jaxen XPath engine; my static analysis utility PMD is among the many satisfied Jaxen customers.
The Army reading list
Actually, there are a number of xUnit implementations out there. JUnit is just one of many for many languages. NUnit is by no means a rip off of JUnit than JUnit is of pyUnit, or cppUnit, etc.
For more info on xUnit testing frameworks for many different languages and platforms see (way down the page is a table):
http://www.xprogramming.com/software.htm/
Cadmann
To recap in manager-speak, you're saying the utilization of utilize nets suboptimal perceptual leadership utility?
What continues to stun me about the "professional" developers out there is how few do Unit Testing even when it is so easy. People complain about jobs moving offshore and pressure on delivery and people not understanding how hard coding is... but they don't even Unit testing.
If you don't unit test then you aren't a software engineer, you are a typist who understands a programming language.
An Eye for an Eye will make the whole world blind - Gandhi
I've also been recently poking at Jmock and CGLib for my testing system as well.
Jmock's built on top of junit, so it uses the same mechanisms, and can produce test cases the same way (ie, it works in eclipse's junit view :) ).
Using JMock, one can create mock objects for interfaces that expect various functions to be called some number of times with particular sets of arguments. I believe they can even be configured to throw various exceptions
This is handy in the junit sense so that you can test classes in isolation.
Of course, this only works for classes with predefined java interfaces. So toss cglib into the mix, and jmock will happily use that to create mock classes out of concrete classes instead! (basically by using an alternative to the java reflections api). Doesn't require native libraries either, still all java based, and still all opensource.
Like I say, looking very handy for my next major project which we're just finishing the design stage of at uni :).
That said, I haven't tried anything too complex with it yet, and the mock objects toss out some weird error messages if you mistype a function name or parameter :) )
ashridah
Unless your application is database driven.
As of several months ago, when I last looked, there is no easy way to do automated unit testing on an application that requires a existing dataset for each unit.
DBUnit made an attempt but it was far from realistic and did not scale in anyway to the enterprise level. What?? You mean I have to store my schema as XML? That's re-goddamn-tarded.
Everything ends up a kludge that is extremely difficult to maintain. If people have seen different, please share.
1;
A famous rapper named 50 Cent has a click/gang/group called G-unit. They often say "G-G-G-G-G-G-UNIT" in their songs so people can recognize who they are. Saying "J-J-J-J-J-J-UNIT" is just a play off of this.
I was actually thinking more Moon Unit, myself.
The World Wide Web is dying. Soon, we shall have only the Internet.
Fixtures is something that JUnit has been ignoring since its inception and thus it is much less appealing than it could be if the test fixture dillemma is ever solved.
Your pizza just the way you ought to have it.
Envy me, I'm programming's MVP!
Hollow words will burn and hollow men will burn.
However, I see very little effort put into end-to-end system tests, and that's a shame. The really tricky bugs come from module/process interaction. Furthermore, unlike Unit Tests, system tests reflect the end-user experience. At one place where I worked, the software was just pure crap, but the system testing was thorough and the customers loved the product.
Test 1 2 3 4
Someone once referred me to Cactus, which is an extension of JUnit.
It only helps you for web apps, though.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
My idea would be to tackle the mocking scenario by intercepting methods with AOP (AspectJ most likely) and subsituting mocked return values. This would at least make it possible to unit test legacy code without major refactoring and avoid some really questionable design decisions that junit sometimes forces you into.
Your pizza just the way you ought to have it.
JUnit was actually the first - it was written back when people were still figuring out to call it "unit testing" as distinct from functional testing, and it was certainly the first widely used framework that supported unit testing.
In that sense, all the other xUnit stuff is decidedly a descendant of JUnit.
Like JTiger has done for ages?
Looks like JUnit4 is adopting most of its ideas from TestNG. This is good, as JUnit feels highly constrained and somewhat crippled compared to TestNG, but why even bother with JUnit4? TestNG can run JUnit tests unaltered, so backwards compatibility isn't really an issue.
Unless JUnit is going to add quite a few more features, it still won't be nearly as flexible as TestNG. I think the JUnit developers are stuck on this idea of independent tests, which certainly has its merits but ends up excluding a lot of powerful options or forcing you to use ugly workarounds.
TestNG is more of an all-purpose testing framework, equally adept at unit testing as well as higher level functional testing. As a developer, I want to be able to test things in whatever way fits the task at hand. For instance, sometimes it's easier or arguably makes more sense to test a multi-step process (say, user registration and verification) in a defined order. This is possible with JUnit, but it definitely goes against the grain of the framework, which does not support test dependencies and therefore doesn't support ordered tests. I don't appreciate being penalized by a framework because its developers have a very specific concept of "pure" unit testing.
Perhaps I should elaborate: I'm sure the JUnit developers know far more about unit testing that I do, but I want to write more than just unit tests. I'm perfectly happy to admit to writing functional and acceptance tests (and even tests that talk to a real database) in addition to true, pure unit tests. I understand why the differences should be recognized, but the fact remains that JUnit simply does not accomodate a broader view of testing.
I hate to be critical of something that's brought so much improvement to how we write code (JUnit), but I think we've all learned a lot about unit and other types of testing and it's time to move on to something that embodies those lessons.
Almost. The Smalltalk version (SUnit) was the original which inspired JUnit. It wasn't the watershed that JUnit was due to the relative popularity of the languages.
At any major development place, *everything* is unit tested. Code coverage (how many lines of code are actually covered by the tests) is huge and should usually be above 70%. Unit tests aren't to make sure that your code is working correctly right now, unit tests are so that in 5 years when you change one class out of 6000 interdependant classes you can just run "ant test" and it goes back, runs all your tests and makes sure they still pass as they did when you first wrote it 5 years prior. Without unit testing, modifying any major, complex piece of software would be hopeless. You can unit test anything, including apps that require databases. You simply "mock out" the database using JMock and it stands in place for it like a fake database almost. The development I do is heavily dependant on Oracle and Java and JUnit/JMock are critical to the project's success. It is a common practice in open source now too as was seen by the recent release of Gallery 2.0 which is largely unit tested.
Regards,
Steve
Interesting you've judged something impossible that thousands of professional developers perform daily.
Using mock objects makes unit testing servlet code pretty easy. Keeping your objects reasonable in size and single purposed in function also simplifies testing. If a servlet is so complex that its hard to test then, that is a sign that it should be broken up and delegate to smaller classes with simpler methods that are easy to test.
JSP's should not have any logic in them, or if they do, it should be trivial. With no logic, there is nothing to test. Move the logic into a servlet (or Action for struts) or for presentation logic, put it in a custom tag. Then you have java that can be validated with the compiler and easily tested.
HttpUnit is very easy to use for testing live web applications but, its reaching beyond the scope of Unit testing and getting into the realm of Acceptance and Integration testing (better tool for qa than a developer).
Stuff in the rights places? Page formatted correctly? Sounds like you want screen capture and image analysis, maybe NASA can help you. JK, really, at some point you just have to look at your pages in the various browsers.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Some of my professors have developed a tool to help structual testing. JaBUTi (Java Bytecode Unterstanding and Testing) can test java applications and components even it the original java source code isn't available. It is possible to do the structural test through several approachs, like control-flow (all-nodes, all-edges) and data-flow (all-uses, all-potential-uses).
2 131
I have used this tool during some time and it is amazing. It generates graphs of the code you are testing and it can be integrated with junit.
Check this paper for more details: http://portal.acm.org/citation.cfm?id=1072118.107