Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Programming

An Early Look at JUnit 4 147

Posted by ScuttleMonkey from the still-just-java dept.
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."
This discussion has been archived. No new comments can be posted.

An Early Look at JUnit 4 More

An Early Look at JUnit 4

Comments Filter:

  • I don't know if I am the only one thinking this... (Score:5, Funny)

    by TheOtherAgentM ( 700696 ) on Wednesday September 14, 2005 @05:14PM (#13560861)
    Maybe I am the only one that understands this too... J-J-J... J UNIT!

  • Too bad (Score:5, Interesting)

    by cached ( 801963 ) on Wednesday September 14, 2005 @05:15PM (#13560869)
    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.
    • Eclipse was actually my first experience with pre-defined test cases. And in order to make a GUI test, it's hard to think of the logistics. How exactly is it wrong if a control is one pixel down, or if it doesn't use the right layout. What they really need is an on-the-fly GUI editor. Not a form-editor, but a way to change the code, and reissue a pack in order to change the UI.
    • And I sure don't understand why. I mean, given the GUI test runner from JUnit 3, and the text test runner from JUnit 4, is it really that hard to produce a GUI test runner for JUnit 4?

      This is annoying enough that somebody's going to just hack one out, unless there's some technical reason why it can't be done that's eluded me...

    • RE: Too bad (Score:2, Informative)

      by Slurm ( 147172 )

      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.

      Why bother with GUI testrunners when you can just create a nice set of webpages containing your JUnit results in detail? That

    • Reminded me how at one of my jobs I rigged Swing TestRunner to display different shade of red/pink etc. depending on number of failures.
      It was my silent protest against the culture where it was "ok" if not quite all the tests passed.
      "How are the tests? - still pink!"
  • As much as the student programmer in me would want to say "Who needs testing, I'm perfect!" I have to admit, this looks impressive. Expected exceptions look pretty useful, although I'm wondering if the syntax is actually proper java coding. If this is an open-source solution, it would be an extremely useful tool to have.

    • Re:Testing (Score:3, Informative)

      by ashridah ( 72567 )

      I've also been recently poking at Jmock [jmock.org] and CGLib [sf.net] 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

      • Re:Testing (Score:3, Insightful)

        by MSBob ( 307239 )
        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.

    • Re:Testing (Score:3, Insightful)

      by LnxAddct ( 679316 )
      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 tes
  • 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.
  • That supported attributed programming years ago? Oh I know, NUnit is a port^H^H^H^Hripoff of JUnit so it doesn't count.
    • 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/ [xprogramming.com]

      Cadmann
      • I think his point is more specifically about marking your code with .NET "attributes" to specify the method is a test etc.

        In other words, Java added a new feature to the language in Java 5 (called "annotation") which was something that .NET had (called "attributes") and now the new JUnit is allowing you to mark your methods specifically as tests to be run (like NUnit has for quite some time).
        • I understood his point, and am aware that NUnit uses attributes, and think its cool if the JUnit guys want to add it. Of course, a valid point here is that the Java stuff gets attention, and perhaps the .Net stuff does not....

          I was addressing the fact that the xUnit community (at least the various folks that like/use/support the xUnit-style implementations, don't look at NUnit being a "rip-off" of JUnit. I think its great that NUnit initially learned from JUnit (and they from the smalltalk, c++ versions,
          • No problem. I'm sure his comment was definitely a backlash against the people who spell Microsoft with a "$" :). He was just trying to show something that went the other way in the typical "rip off" arguments (both from a language and xUnit standpoint ).

            I try to stay neutral on the "X" ripped off "Y" arguments. It turns out that a lot of the time when people "reinvent the wheel", they end up doing a slightly better job since they have the benefit of hindsight.

            If you do any .NET stuff in Visual Studio by the
            • You had the right read on my post. Just trying to cut through the anti-Microsoft bias a bit.

              When Microsoft copies something from Apple, there's a huge dustup. When the Java VM starts catching up to CLR features (I have used both extensively) it's "innovating". They both copy each other a lot, obviously, but I get a bit tired of the one-sidedness sometimes.

      • 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.
      • 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.

        The original poster's point was, NUnit (and csUnit) both support unit tests marked up with .NET attributes (sorta kinda like Java annotations), and they've done it for quite some time now. Yet neither of these have made the front page of Slashdot.

        The point was lost in the vitriol and flame but I think it still stands.
  • ...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.

  • Java 5, JUnit4 (Score:3, Interesting)

    by ReformedExCon ( 897248 ) <reformed.excon@gmail.com> on Wednesday September 14, 2005 @05:21PM (#13560925)
    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.

    • Re:Java 5, JUnit4 (Score:3, Interesting)

      by Surt ( 22457 )
      The @Test annotation allows you to drop the test from your test method name. This is a minor help it:

      a) reduces the method name length slightly, there are various tools that aren't up to handling super long method names.

      b) more importantly, can simplify your naming conventions

      way way way more important is that
      extends TestCase

      is no longer necessary, which since Java is single inhertiance model now means you can extend something else with your test classes. As one significant example, think about writing te

      • Re:Java 5, JUnit4 (Score:3, Informative)

        by iabervon ( 1971 )
        I haven't looked at the details yet, but I think you're supposed to be able to affect compilation using annotations, and you can certainly have tools post-process class files using annotations. What that means is that you can have a "production build" which strips out everything annotated with the JUnit annotations, and have your tests actually in the class they're testing, but have them not end up in the final application. Then it's easy to find the tests for a class (they're in the same class) and the tes
  • But wikipedia says Junit was a minor goddess [wikipedia.org].

    Just kidding, JUnit [wikipedia.org], one with capital U.

  • The Holy Grail (Score:3, Interesting)

    by Catamaran ( 106796 ) on Wednesday September 14, 2005 @05:23PM (#13560943)
    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 [ptc.com] has this capability. Are there other applications that can do that?

    • Re:The Holy Grail (Score:4, Funny)

      by KenSeymour ( 81018 ) on Wednesday September 14, 2005 @06:22PM (#13561394)
      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.
      • Hey, I think we work for the same company!

        Yes, JUnit is nice. All of the XUnits are nice. They address one of the major problems in software development, which is the constant divergence of tests and code. But there are other ways to address that problem. The method that I subscribe to is this: don't allow developers to check in code until it passes all existing tests. It takes come descipline, but it works.

        By the way don't forget to patent that microphone idea.

    • Re:The Holy Grail (Score:5, Funny)

      by willCode4Beer.com ( 783783 ) on Wednesday September 14, 2005 @08:10PM (#13562267) Homepage Journal
      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.

  • More on Elliotte (Score:5, Informative)

    by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Wednesday September 14, 2005 @05:23PM (#13560946) Homepage
    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 [ibiblio.org] and has written a slew of excellent books.

    He's also a committer on the open source Jaxen [jaxen.org] XPath engine; my static analysis utility PMD [sf.net] is among the many satisfied Jaxen customers.
  • "Utilize" would be "use" if you were speaking plain English. And no, using the word "utilize" doesn't make you seem any smarter.

    • Re:Could we cut down at manager speak here (Score:4, Funny)

      by iggymanz ( 596061 ) on Wednesday September 14, 2005 @05:34PM (#13561041)
      To recap in manager-speak, you're saying the utilization of utilize nets suboptimal perceptual leadership utility?

    • Usage Note: A number of critics have remarked that utilize is an unnecessary substitute for use. It is true that many occurrences of utilize could be replaced by use with no loss to anything but pretentiousness, for example, in sentences such as They utilized questionable methods in their analysis or We hope that many commuters will continue to utilize mass transit after the bridge has reopened. But utilize can mean "to find a profitable or practical use for." Thus the sentence The teachers were unable to u

    • ...especially when spelled with a "z" instead of the proper "s"...
      • For most non-American speakers of English (as well as many Americans), the Oxford English Dictionary is the reference for the spelling of English words. Well, the OED lists the -ize spellings as the primary spellings for most words (but not analyze/analyse). Here is a link [askoxford.com] for you.

        On a related note, the word 'soccer' was introduced by the British, as well. It seems that the move towards "-ise" and football are attempts by the Brits to appear more like the French.
        • Hmm... what's wrong with "soccer", exactly? I think it's a good idea to distinguish the sport names when there are at least five different kinds of "football".

  • JUnit and the people who don't use it... (Score:3, Insightful)

    by MosesJones ( 55544 ) on Wednesday September 14, 2005 @05:35PM (#13561048) Homepage

    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.

    • Re:JUnit and the people who don't use it... (Score:4, Insightful)

      by kevin_conaway ( 585204 ) on Wednesday September 14, 2005 @05:46PM (#13561122) Homepage
      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.
      • Welcome to the unprofessional developer Island... population you.

        Normally, writing junit tests is less then or equal to the amount of work in writing the actual code

        Where as fixing the bugs as a result of a lack of unit testing doesn't take any effort at all.

        You muppet.

        • Grr. I'm not arguing against them in general. We write them for our backend components. Writing them for a GUI or Web module however takes more time than its worth.
        • Your personal comments are out of line and show your immaturity in the software world.

          Fixing bugs as a result of a lack of unit testing does take effort. In some cases, bugs make it to production. But in the case of enterprise scale web applications backed by complex databases, Unit Testing takes 2 - 3 times as much work. It slows down development as you are not only updating test code along with your application code, but you are also updating your schema *and* your test data.

          Don't think I'm not for

          • Don't think I'm not for Unit Testing. Believe me, I'm an advocate of it here at work. In any situation we can (typically our libraries), we have unit tests with JUnit. But it just does not work when:

            - you have complex web GUI that cannot be emulated with test frame work.
            - you have complex database schema backing your application.

            It certainly can work in those situations, as developers have been doing this for years.

            You can use HTTPUnit to automatically generate http requests, form data, and to valid
        • The point, dummy, is that it's next to impossible to use Junit to test servlet code, and downright impossible* to use it to test JSPs. Unfortunately, other than things like HTTPUnit (which last time I looked was almost useless) and WinRunner (which costs and only runs on Windows) there isn't a lot available for proper interface testing of web pages. Not just screen scraping, "do I get the expected data?", but proper "all of the formatting is correct, images in the right place, etc" testing.

          (* No, nothing is

          • mock objects (Score:3, Interesting)

            by willCode4Beer.com ( 783783 )
            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
      • A testing framework for webapps that runs in the browser. It's both slick and simple.

        http://selenium.thoughtworks.com/index.html [thoughtworks.com]
      • Ruby on Rails (http://www.rubyonrails.com/ [rubyonrails.com] makes unit and functional testing very very easy.

        It's incredibly easy. One of the reasons why I like the framework so much.
      • You don't "unit test" web applications, the unit test concept refers to testing units of code, not whole applications. If you want to assert that a whole application is working as intended, the concept you are talking about is "functional testing".

        Anyway, a great tool for testing web applications is Selenium. Look for the link in another response to your post.

        Fh
    • Well, not really, but my experience has been quite different. I don't know anyone who doesn't at least pay lip service to the concept of Unit Testing. In fact most developers I know follow a pattern of code a little, test a little.

      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 p

    • > If you don't unit test then you aren't a software engineer, you are a typist who understands a programming language.

      I think it's the other way around -- if you think passing unit tests means your code is perfect, then you are a typist who understands a programming language.

      Here's a simple example:

      int add(int a, int b) { return a * b; }
      boolean testAdd(){ if(add(2,2) == 4) return pass; else return fail; }

      Hey, the test passed, your code must be correct, right?

      If you do manage to test all possible cases th
  • When and if I will bother to look at Java 5 I will look at JUnit, but this interesting Annotation feature of Java 5 sounds a lot like a precompiler ;)

    But why do they not want to ship this new JUnit 4 with the JUnit GUI runner? Did they decide to split the projects?

    From the blog I can see that JUnit 4 will not be able to differentiate between the anticipated errors from asserts and unanticipated errors from code - now that will prevent me from converting to JUnit 4 even if I move to Java 5.
    • I've looked at Java 5 and I am really pushing for it to be adopted in my workplace. The new programming semantics make the code more readble and faster to program - the for loop for example, no more java.util.Iterator! Annotations are kind of handy but when it comes to the JUnit 4 and TestNG methodology of testing it's embedding the tests in your code. The original idea for subclassing was so you had that separation of test code and production code - why double your production code with the test cases? No
      • No doubt Java 6 is out next February and Java 7 the following february so how much longer can Java 1.4 be considered mainstram?

        I support at least one application that runs on 1.2.

  • Maybe, but it doesn't work with databases... (Score:3, Informative)

    by digerata ( 516939 ) on Wednesday September 14, 2005 @05:43PM (#13561099) Homepage
    Many feel that this is one of the most important third-party Java libraries ever developed.

    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.

    • DBUnit didn't scale to the enterprise level? It's a fuggin test tool. What scaleability are you talking about.

      As for the XML...I have mixed feelings about it but it makes sense when you think it through. In any event, DBUnit will export the XML from your db for you.

    • Re:Maybe, but it doesn't work with databases... (Score:5, Interesting)

      by prisonercx ( 40652 ) on Wednesday September 14, 2005 @06:01PM (#13561230)
      I understand your frustration. One workaround I've seen uses the Spring framework's annoyingly-named AbstractTransactionalDataSourceSpringContextTests [springframework.org]. Your test classes subclass that monstrosity, and after each test method is run the transaction is rolled back to avoid mucking up the DB for subsequent tests. When you test DAOs, you have to have a custom method for inserting test data before or during each test. Once you get above the data access layer, you just use your now-tested DAOs.

      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.

      • "Once you get above the data access layer, you just use your now-tested DAOs."

        Huh? When you get above the data access layer, you create a mock DAO that implements the interface and use that to test your business objects. Christ, that's the whole damned reason why Spring is such an excellent unit test enabler: you can easily mock out interfaces and test components in isolation. Which is the very definition of unit test (as opposed to integration or system-level test).

    • It's not so bad. The application I'm working on at work is backed by a database, and all we do is keep around a bunch of precooked databases, take a copy of the database (copying the files is enough) and run all the tests on that.

      One of the ways you can cheat the system is if you have the capability to control the transactions from the unit tests, you can set a save point before the unit test and roll back to it after the unit test, so that the next tests don't get trash data from the previous ones.

      And y

    • Why can't you mock out the database?
      Regards,
      Steve
    • If you can, switch to JDO. Among all the other great benefits, DB related testing goes down in both volume and difficulty. After 2 years with JDO, I can't imagine not using it. I recommend http://www.solarmetric.com/ [solarmetric.com]

    • 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.

      Get your hands on Working Effectively with Leagacy Code by Michael C. Feathers. And do it soon.

      Don't let the term "legacy code" in the title throw you off. Feathers calls any code that is not covered under automated testing "legacy code." On p. 17 of the book, Feathers gives an example of how to test code that currently requires hitting a databa

  • Writing JUnit tests for Web and GUI applications can be as time consuming, and usually more time consuming than writing the application itself.

    Can anyone recommend a good framework for testing these components?

    • We usually design the entire GUI to be properly separated into model/view in the first place, so that we can thoroughly test the model to the point where we know that no matter what bug might exist in the UI itself, the user won't be able to find it. ;-)

      What you're looking for for web stuff is probably HttpUnit. There is an equivalent for Swing apps too, but we've tried it and it really took more time (10 times more) to write the tests than to write the code, so we decided against it.

    • Re:Web / GUI (Score:3, Informative)

      by KenSeymour ( 81018 )
      Someone once referred me to Cactus, [apache.org] which is an extension of JUnit.

      It only helps you for web apps, though.

    • I have used JUnitEE [junitee.org] for some time. It provides a Servlet runtime for your tests/test suites. It makes JUnit alot easier to deal with for some type of testing.

      Of course, if you are smart you will write an Ant script that will fire off tests for you (using conventional JUnit)... but that only works for some things and it depends on how well you write your tests.

    • Try Selenium: http://selenium.thoughtworks.com/index.html [thoughtworks.com]

      It's better than HTTPUnit as it runs your app in a browser, rather than trying to emulate a HTTP client and failing to support complex JavaScript.

      Supports Fit Test scripts.
    • No, but I can recommend another framework that you can make apps with that needs no testing:

      Haskell.

  • Super off-topic (Score:1, Informative)

    by Anonymous Coward
    Can anyone tell me why this story was rejected:

    With Visual Studio .NET 2005 and the .NET 2.0 run-time not even out of beta, Microsoft has released the C# Version 3.0 Specification (doc format) at their http://msdn.microsoft.com/events/pdc [anonymouse.org]">Professional Developers Conference 2005. http://msdn.microsoft.com/vcsharp/future/ [anonymouse.org]">New features include SQL-like and XQuery-like query expressions, implicit (on initialization) typing, lambda expressions and more. The primary focus of the language extensions are

  • Useless (Score:3, Interesting)

    by MSBob ( 307239 ) on Wednesday September 14, 2005 @06:01PM (#13561224)
    The change that all unit test frameworks need is to address the issue of creating complex setups that your code typically relies upon to execute its tasks properly. Whether it be through mock objects or proper environment setup, at the moment it is the biggest PITA and many, many developers question whether the effort of maintaining those setup fixtures is worth the benefit of unit testing.

    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.

    • The requirement of complex setup for tests suggests one of two things:
      Your tests may be beyond the scope of "unit" tests. Integration tests maybe?
      The code needs to be broken up into simpler units that are easier to test individually.

      Regarding the first case, how would you validate the code without testing?
      The second is just some code that requires refactoring.
      • The code needs to be broken up into simpler units that are easier to test individually.

        this is a cliche ofter repeated by the proponents of JUnit. Often times refactoring your code to make it compatible with JUnit results in the code structure more complex than if JUnit had been more transparent. This is bad refactoring as it flies in the face of simplicity as the overriding principle in software design.

        I do have some ideas about how to dramatically overhaul the JUnit paradigm with Aspect Oriented unit

        • Actually, before JUnit was a thought, this was an idea pushed to support clean, logical, maintainable, and well designed code. If a method is easy to test that might indicate that it has a well defined purpose and a well defined interface, these are good things even if you don't care about testing, agile dev or whatever. Before agile, this just used to be called good code.
          Maybe that "bad refactoring" isn't so bad after all. Code shouldn't be refactored to JUnit, it should be refactored to be well structured
  • Here are a couple of articles explaining why the distinction between tests and unit tests are becoming irrelevant:

    http://www.theserverside.com/news/thread.tss?threa d_id=36502 [theserverside.com]
    http://beust.com/weblog/archives/000319.html [beust.com]
    • You linked to two opposing articles. One that tries to narrowly define unit testing and then Cedric's critique of that article. I'm interested, what exactly did you mean? Do you just think that the *term* "unit test" is becoming irrelevant or the actual act of writing unit tests?

  • been there, done that (Score:3, Informative)

    by vidnet ( 580068 ) on Wednesday September 14, 2005 @07:18PM (#13561823) Homepage
    simplify testing by exploiting Java 5's annotation feature

    Like JTiger [jtiger.org] has done for ages?

  • Why not just use TestNG? (Score:4, Informative)

    by CryBaby ( 679336 ) on Wednesday September 14, 2005 @07:18PM (#13561826)
    Looks like JUnit4 is adopting most of its ideas from TestNG [testng.org]. 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 [theserverside.com], 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.
    • as soon as I saw you had to create a freaking XML file I stopped reading. eclipse can run junits without all the xml junk. java and XML don't require each other!
      • Yeah, I can understand why a lot of Java programmers have formed a deep-seated hatred of XML ;-).

        I think there are places where XML makes sense and places where it doesn't. Overall though, I share your bias because it all adds up.

        Having said that, TestNG's configuration file is almost trivial, especially compared to the XML I'm sure you already deal with if you're using any kind of frameworks, O/RM or any J2EE stuff.

        Technically, TestNG does not even require an XML file - but I've found that in practic
  • Don't annotations use reflection?

  • Check this paper (Score:5, Interesting)

    by gustgr ( 695173 ) <gustgr@gma[ ]com ['il.' in gap]> on Wednesday September 14, 2005 @08:00PM (#13562186)
    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).

    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.1072 131 [acm.org]

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close