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.
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.
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?
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.
Unit testing for web apps has a long way to go. Normally, writing junit tests is less then or equal to the amount of work in writing the actual code. Writing unit tests for web applications is vastly more complex and time consuming.
It requires you to define the way you get your database connection through Spring, but that abstraction is necessary for unit testing DB-driven apps anyway. On one of my projects, I have one set of bean descriptions for unit testing which connects right to the DB and one set of beans for when the app is running in a Tomcat container. It's not a perfect method, that's for sure, but it allows me to unit test my code pretty painlessly once it's set up.
Envy me, I'm programming's MVP!
Hollow words will burn and hollow men will burn.
The system I am looking for would use microphones to record all the conversations regarding requirements, resolve them into structured documents, then generate unit tests for all the requirements.
It would have to use microphones because, in my experience, you don't get a written requirements spec. Or if you do, customers don't feel constrained by it.
It would also have to raise a red flag when the customer contradicts themselves in the same sentence or paragraph.
But all kidding aside, JUnit is cool.
For intricate portions of my code I write tests that represent specific scenarios and run regression tests whenever I have finished implementing the new rule of the day.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
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
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
I say the holy grail is combining unit testing with genetic algorithms.
Then you just write the tests and let the code "evolve" until it passes them. Meanwhile, you get to sit around and drink beer.
----- If communism is a system where the government owns business, what do you call a system where business owns govern