Slashdot Mirror

← Back to Stories (view on slashdot.org)

An Early Look at JUnit 4

Posted by ScuttleMonkey on 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."

147 comments

  1. I don't know if I am the only one thinking this... by TheOtherAgentM · · Score: 5, Funny

    Maybe I am the only one that understands this too... J-J-J... J UNIT!

  2. Too bad by cached · · Score: 5, Interesting

    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.
    1. Re:Too bad by AndreiK · · Score: 1

      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.

    2. Re:Too bad by Anonymous Coward · · Score: 0

      Java is open source. It's just not under the communist GPL.

    3. Re:Too bad by attonitus · · Score: 1
      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

      The parent is referring to a GUI to run the tests, not a test to test a GUI.

    4. Re:Too bad by Anonymous Coward · · Score: 0

      Java is open source.

      Just like Microsoft's "Shared Source" is open source too!

    5. Re:Too bad by rewt66 · · Score: 1

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

    6. RE: Too bad by Slurm · · Score: 2, Informative
      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 way anyone with a web browser can take a look. In your Ant buildfile, have JUnit output the results as XML, and use the junitreport task to automagically transform it to HTML.

      For a small amount of effort, you'll get something like this.
      --
      There comes a time in every friendship when you have to say, "I never liked you, get lost." --Bill McNeil
    7. Re:Too bad by AndreiK · · Score: 1

      Oh, I thought that that was kinda assumed. I'm used to the eclipse panels.

    8. Re:Too bad by BigGerman · · Score: 1

      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!"

    9. Re:Too bad by Anonymous Coward · · Score: 0

      No, it's not. Sun *do* provide the source code; however they do so under conditions that basically prohibit doing anything more than reading that source. Useful, but a long way short of any definition of 'open source'.

    10. Re:Too bad by Anonymous Coward · · Score: 0

      That's some good karma whoring - copy paste a paragraph from TFA and get +5! I salute you!

  3. Testing by AndreiK · · Score: 1

    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.

    1. Re:Testing by ashridah · · Score: 2, Informative

      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

    2. Re:Testing by MSBob · · Score: 2, Insightful

      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.
    3. Re:Testing by LnxAddct · · Score: 3, Insightful

      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

    4. Re:Testing by Beek · · Score: 1

      > Unit tests aren't to make sure that your code is working correctly right now

      Well, if you're doing test-first development, you're writing unit tests to make sure your code running correctly right now. And you get the long-term benefits for free :)

  4. Look around you by Eunuch · · Score: 2

    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.
  5. Where was the headline when NUnit was released? by soconnor99 · · Score: 1, Insightful

    That supported attributed programming years ago? Oh I know, NUnit is a port^H^H^H^Hripoff of JUnit so it doesn't count.

    1. Re:Where was the headline when NUnit was released? by CadmannWeyland · · Score: 3, Informative

      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

    2. Re:Where was the headline when NUnit was released? by Kentamanos · · Score: 1

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

    3. Re:Where was the headline when NUnit was released? by CadmannWeyland · · Score: 1

      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, etc.), and that in turn JUnit is learning from NUnit.

      IMHO (and part of my point) is that the xUnit framework stuff has always been multi-language and is outside the whole religious java vs .net vs whatever arguments. It's way cool to me as a test-first developer that I can probably find an xUnit implementation for just about any language I run into.

      Cadmann

    4. Re:Where was the headline when NUnit was released? by Kentamanos · · Score: 1

      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 way, be sure you've looked at http://www.testdriven.net/. It's a very sweet way to do unit tests with NUnit (and other test suites) within Visual Studio. It allows you to right click within a test method and run it as a test etc. Very handy...

    5. Re:Where was the headline when NUnit was released? by PostItNote · · Score: 2, Informative

      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.

    6. Re:Where was the headline when NUnit was released? by Curt+Cox · · Score: 3, Informative

      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.

    7. Re:Where was the headline when NUnit was released? by soconnor99 · · Score: 1

      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.

    8. Re:Where was the headline when NUnit was released? by Calroth · · Score: 1

      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.

  6. Just when I'd almost gotten comfortable by Elrac · · Score: 2, Funny

    ...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
  7. Java 5, JUnit4 by ReformedExCon · · Score: 3, Interesting

    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.
    1. Re:Java 5, JUnit4 by Surt · · Score: 2, Interesting

      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 tests that extend the tested class, and how that helps to better maintain the protection mechanism.

      No doubt about it, this will be a big step forward in JUnits power.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    2. Re:Java 5, JUnit4 by iabervon · · Score: 2, Informative

      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 tests can even peek at private fields, which is really nice, because sometimes you don't want subclasses messing with some of the fields you want to test.

  8. JUnit4 ? Goddess ? by karvind · · Score: 2, Funny
    But wikipedia says Junit was a minor goddess.

    Just kidding, JUnit, one with capital U.

  9. The Holy Grail by Catamaran · · Score: 2, Interesting

    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
    1. Re:The Holy Grail by KenSeymour · · Score: 3, Funny

      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
    2. Re:The Holy Grail by Catamaran · · Score: 1
      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.

      --
      Test 1 2 3 4
    3. Re:The Holy Grail by Anonymous Coward · · Score: 0

      I think JUnit is trying to serve a different need. For instance, if this artcle was a review of Pro/Engineer I would wonder how it might support test driven development.

      Maybe doing TDD with Pro/Engineer should be called Catch 22 Development.

    4. Re:The Holy Grail by willCode4Beer.com · · Score: 4, Funny

      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
  10. More on Elliotte by tcopeland · · Score: 4, Informative

    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
    1. Re:More on Elliotte by Anonymous Coward · · Score: 0

      I had the opportunity of learning java from this guy. He was absolutely horrible. He gave everybody A's, though a few people missed his final. He also thinks he's very funny - he'll laugh at his own jokes, while everyone gets kinda.. uncomfortable.

    2. Re:More on Elliotte by Anonymous Coward · · Score: 0

      Elliotte?

      Sounds like a guy who eats paste.

    3. Re:More on Elliotte by Anonymous Coward · · Score: 0

      CS905 in Poly, right? I dunno, I took his class as well, I think he does a great job teaching Java and OOP.

    4. Re:More on Elliotte by Anonymous Coward · · Score: 0

      To clarify, Elliotte's site is http://www.ibiblio.org/javafaq/

      ibiblio.org is a broad collection of sites, including Elliotte's; the director is Paul Jones. But I guess most everyone knows all this already...

  11. Re:JUnit4 by Dr+Reducto · · Score: 0, Offtopic

    How is the parent off topic?

    It at least deserves a "funny" mod

  12. Could we cut down at manager speak here by melted · · Score: 1, Insightful

    "Utilize" would be "use" if you were speaking plain English. And no, using the word "utilize" doesn't make you seem any smarter.

    1. Re:Could we cut down at manager speak here by iggymanz · · Score: 3, Funny

      To recap in manager-speak, you're saying the utilization of utilize nets suboptimal perceptual leadership utility?

    2. Re:Could we cut down at manager speak here by melted · · Score: 1

      >> To recap in manager-speak, you're saying the utilization of utilize nets suboptimal perceptual leadership utility?

      No, it simply doesn't leverage any paradigm leading to go-to market, customer focused synergies.

    3. Re:Could we cut down at manager speak here by strcmp · · Score: 1
      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 use the new computers might mean only that the teachers were unable to operate the computers, whereas The teachers were unable to utilize the new computers suggests that the teachers could not find ways to employ the computers in instruction.

      From dictionary.com

      --
      "Yields falsehood when preceded by its own quotation" yields falsehood when preceded by its own quotation.
  13. Re:I don't know if I am the only one thinking this by Anonymous Coward · · Score: 1, Funny

    You must be that famous rapper's computer-geek brother, 50 GHz...

  14. Re:I don't know if I am the only one thinking this by ViaNRG · · Score: 0

    Yes! When I saw this headline, I so had my fingers crossed for that to be first post! You rule!

    --
    Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. -Heinlein
  15. G- no J-Unit by qedigital · · Score: 0, Redundant
    j-j-j-jaay-uuunit!

    sorry, it's the first thing that sprang to mind upon reading the headline

    --

    Rapidly approaching the Zener knee...

  16. Re:Fo' Shizzle! by Anonymous Coward · · Score: 0

    Hahaha.. I was gonna say this! C'mon people lighten up a little bit and mark this funny! Naw mean?!

  17. JUnit and the people who don't use it... by MosesJones · · Score: 2, Insightful


    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
    1. Re:JUnit and the people who don't use it... by kevin_conaway · · Score: 3, Insightful

      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.

    2. Re:JUnit and the people who don't use it... by MosesJones · · Score: 0, Troll

      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.

      --
      An Eye for an Eye will make the whole world blind - Gandhi
    3. Re:JUnit and the people who don't use it... by kevin_conaway · · Score: 1

      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.

    4. Re:JUnit and the people who don't use it... by digerata · · Score: 1
      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 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.

      --

      1;
    5. Re:JUnit and the people who don't use it... by Anonymous Coward · · Score: 0

      You're the muppet, apparently you can't even read simple English.

    6. Re:JUnit and the people who don't use it... by Tim+C · · Score: 2, Insightful

      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 impossible - but using junit to test JSPs is the next best thing, especially when you actually have a deadline to meet)

      JUnit is a woderful tool for testing plain old Java objects, but is utterly unsuitable for end to end testing in a web (or other GUI) environment.

      --
      It's official. Most of you are morons.
    7. Re:JUnit and the people who don't use it... by swimmar132 · · Score: 1

      Ruby on Rails (http://www.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.

    8. Re:JUnit and the people who don't use it... by Decaff · · Score: 1

      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 validate the results.

      As for the database testing - that is often done using sample data in small databases such as HSQLDB.

    9. Re:JUnit and the people who don't use it... by Felipe+Hoffa · · Score: 1

      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

    10. Re:JUnit and the people who don't use it... by jrockway · · Score: 1

      > 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 then your test is the definition of the method and you shouldn't have even bothered writing it. If your test doesn't completely define the method, then your test misses that one special case and is worthless.

      What's the point of unit tests, again?

      --
      My other car is first.
  18. Not yet with Java5 by roman_mir · · Score: 1

    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.

    --
    You can't handle the truth.
    1. Re:Not yet with Java5 by Anonymous Coward · · Score: 0
      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 ;)
      Annotations are far from being a pre-processor.

      "The metadata feature in J2SE 5.0 provides the ability to associate additional data alongside Java classes, interfaces, methods, and fields. This additional data, or annotation, can be read by the javac compiler or other tools, and depending on configuration can also be stored in the class file and can be discovered at runtime using the Java reflection API."

      Read more here
    2. Re:Not yet with Java5 by tonejava · · Score: 1

      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 doubt Java 6 is out next February and Java 7 the following february so how much longer can Java 1.4 be considered mainstram? NOTE I'm not saying it is not now as that is certainly the case.

    3. Re:Not yet with Java5 by Evil+Grinn · · Score: 1

      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.

      --
      where there's fish, there's cats
  19. Re:I don't know if I am the only one thinking this by Anonymous Coward · · Score: 0

    Sadly, I don't know where its from!

    But I've heard it uttered in the labs while we were Junit'ing... please, where is it from?

  20. Maybe, but it doesn't work with databases... by digerata · · Score: 2, Informative
    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.

    --

    1;
    1. Re:Maybe, but it doesn't work with databases... by badmammajamma · · Score: 1

      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.

      --
      Any man who afflicts the human race with ideas must be prepared to see them misunderstood. -- H. L. Mencken
    2. Re:Maybe, but it doesn't work with databases... by prisonercx · · Score: 4, Interesting
      I understand your frustration. One workaround I've seen uses the Spring framework's annoyingly-named AbstractTransactionalDataSourceSpringContextTests. 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.

    3. Re:Maybe, but it doesn't work with databases... by Trejkaz · · Score: 1

      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 yeah, we don't touch DBUnit... that thing is satanic.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    4. Re:Maybe, but it doesn't work with databases... by Anonymous Coward · · Score: 0

      The whole point of a UNIT test is that you only test one UNIT at a time. You're not testing code+database, you're JUST testing the code. Replace your database interface and a dummy object that supports the exact same interface but only gives the answers you need for the test.

      Your code is well-factored so that you can replace key objects like a Database with other implementations...right?

    5. Re:Maybe, but it doesn't work with databases... by LnxAddct · · Score: 1

      Why can't you mock out the database?
      Regards,
      Steve

    6. Re:Maybe, but it doesn't work with databases... by dwilson837 · · Score: 1

      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/

    7. Re:Maybe, but it doesn't work with databases... by Anonymous Coward · · Score: 0

      JUnit works great, can easily be extended and enhanced to suit your local need. I vaguely remember reading somewhere that Kent Beck did not really want to distribute it in binary form, he wanted to distribute the source and have people just use it as a start point for building their own test frameworks. Is my memory close to the mark?

      One measure of good code is that it is testable. If you choose a technology/design/architecture that is not testable then that is your choice. However, don't blame the testing tools for your design decisions.

      Anyway, JUnit is great for unit testing .... unless you really don't want to do unit testing and are more interested in looking for excuses not solutions.

    8. Re:Maybe, but it doesn't work with databases... by Abcd1234 · · Score: 1

      "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).

    9. Re:Maybe, but it doesn't work with databases... by rookkey · · Score: 1
      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 database:

      Change your code so that it does not call the database implementation directly. Rather, extract the interface of the database implementation into a new abstract class and have the implementation inherit from the interface. Now, you can have two classes inherit this interface: One for the real database implementation code and the other that returns "fake" test data. Then, when you unit test, you never hit the database, but you can still test to see if the logic of the surrounding code works.

      As an example, if you have a method called getInvoices() in a class called DBConnection, then you can create an abstract class called IDBConnection with the method getInvoices(). Have both DBConnection and your new FakeDBConnection class implement this interface. Then you can pass the real or fake database connection object into the calling method and have everything work.

      Feathers gives plenty of dependency breaking strategies that will help in getting more code under unit tests. One of his ideas is that no unit test should take more than 1/10th of a second to execute. If it does, then the code should should be refactored into something more conducive to quick testing. When unit tests run quickly, you're more likely to add more of them. And that's a good thing.

      Again, check out the book and I'm sure you'll find plenty of ways to make the testing process a more fruitful endeavor.

    10. Re:Maybe, but it doesn't work with databases... by durathor · · Score: 1

      I find if you mock out everything the unit tests run great. 100% pass rate every time. The coverage is a little low though.

      Mocking out database access is fine when all you care about is using the resulting data (e.g. when testing post processing of the data). However, when testing the actual database interaction (e.g. SQL generation, SQL driven data processing, data access layer etc.) there is no substitute for backing on to a real database to uncover real errors.

      Then all you need to worry about is cross database support, cross platform support, pre-population of the database, roll-back, comparison against expected results...

    11. Re:Maybe, but it doesn't work with databases... by slushbat · · Score: 1

      I have done quite a bit of testing on one of our database dependant apps using mock objects. Very powerful once I got my head around it. Once you start wanting to test against a real database, it is no longer unit testing, it is system testing, because the code is no longer isolated.

      --

      Don't put off until tomorrow what you can leave until the day after.

    12. Re:Maybe, but it doesn't work with databases... by Anonymous Coward · · Score: 0

      http://www.theserverside.com/news/thread.tss?threa d_id=36502

  21. Re:I don't know if I am the only one thinking this by RUFFyamahaRYDER · · Score: 5, Informative

    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.

  22. Re:I don't know if I am the only one thinking this by Hurricane78 · · Score: 1

    Do you mean:
    Marcy: "Say it! Say it!!!"
    Jefferson: "J-J-J...Joooob"!
    ?

    --
    Any sufficiently advanced intelligence is indistinguishable from stupidity.
  23. Try TestRe:Just when I'd almost gotten comfortable by JSR+$FDED · · Score: 1

    If you want to use an advanced testing framework that works with JDK 1.4 and below, check out TestNG, the framework mentioned in the article and which pioneered many of the concepts being implemented in JUnit 4:

    http://testng.org/

  24. Re:I don't know if I am the only one thinking this by FooAtWFU · · Score: 2, Interesting

    I was actually thinking more Moon Unit, myself.

    --
    The World Wide Web is dying. Soon, we shall have only the Internet.
  25. Web / GUI by kevin_conaway · · Score: 1

    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?

    1. Re:Web / GUI by Trejkaz · · Score: 1

      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.

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
    2. Re:Web / GUI by KenSeymour · · Score: 2, Informative

      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
    3. Re:Web / GUI by ezweave · · Score: 1

      I have used JUnitEE 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.

    4. Re:Web / GUI by Falconne · · Score: 1

      Try Selenium: http://selenium.thoughtworks.com/index.html

      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.

    5. Re:Web / GUI by Anonymous Coward · · Score: 0

      Do you mean how to write unit tests for GUIs? Or do you mean any programmer tests with JUnit? If you mean the latter, I recommend http://abbot.sf.net/. As far as I know, unit tests for GUIs are not really feasible. Be sure to have as few code as possible in your GUI layer so you can unit test most of your code (and thus avoid to spend much time in your debugger) and do some acceptance/functional testing with a bot like Abbot to feel comfortable with your GUI code.

    6. Re:Web / GUI by master_p · · Score: 1

      No, but I can recommend another framework that you can make apps with that needs no testing:

      Haskell.

    7. Re:Web / GUI by elharo · · Score: 1

      Unit tests for GUIs are indeed challenging, but doable. I'll be talking about this (including Abbot) at Software Development Best Practices in Boston in a couple of weeks. I'll put my notes online after the talk.

  26. Super off-topic by Anonymous Coward · · Score: 1, Informative

    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">Professional Developers Conference 2005. http://msdn.microsoft.com/vcsharp/future/">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 encompassed by http://msdn.microsoft.com/netframework/future/linq /">The LINQ Project which aims to bridge the gap between the object-oriented and relational worlds in a simple and type-safe way.

    This is news and it is certainly stuff that matters to nerds. The summary is well written, well linked, and unbias. I also did some searching of slashdot and could not find evidence of the story being a dupe (not that the editors would have noticed).

    So why was it rejected?

    1. Re:Super off-topic by Anonymous Coward · · Score: 0

      You're new here, aren't you?

      Sit back, have some Kool-Aid, and watch the pretty blinkinlights for a little while, and it will all become clear....

    2. Re:Super off-topic by Anonymous Coward · · Score: 0

      First off, you clearly f'ed up this post. If you f'ed up the story submission in the same way, of course it was rejected out of hand. But let's assume you actually formatted your story correctly, included an interesting title, etc..

      This is STILL a very weak story. Whose life will this actually affect? It's a *specification*. These are proposed features, possibly to be added sometime in the distant future (you mentioned yourself that v2 is still in beta). They are not revolutionary features. There's no exciting debate around adding them or not.

      If this were a *release* of these new features, and the features themselves were really an impressive jump forwards, then maybe this would be a story. Keep in mind that the JUnit story you're reading here is still probably just barely worth posting -- in general, basic product version releases are not good stories, *especially* if they are just incremental. Think about it -- what is there to discuss? This is a news discussion website.

    3. Re:Super off-topic by dolmen.fr · · Score: 1

      So why was it rejected?

      Probably because the links are broken.

  27. Useless by MSBob · · Score: 2, Interesting
    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.

    --
    Your pizza just the way you ought to have it.
    1. Re:Useless by willCode4Beer.com · · Score: 1

      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.

      --
      ----- If communism is a system where the government owns business, what do you call a system where business owns govern
    2. Re:Useless by MSBob · · Score: 1
      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 testing, and have a proof of concept working but haven't had the time to turn it into an Open Source project. I will when my work duties get a little lighter, hopefully towards the end of the year.

      --
      Your pizza just the way you ought to have it.
    3. Re:Useless by elharo · · Score: 1

      JUnit's had fixtures for as long as I've been using it, since about 1999 or so. JUnit 4 adds an additional kind of fixture that enables setup and teardown code to run once per test class rather than once per test method.

      However, ultimately if there's too much setup and teardown, you may not really have a unit test. You might be trying to run an integration or acceptance test instead. Admittedly the boundaries are fuzzy, and I cross the line routinely in my own work. However, it is important to remember that JUnit is designed for unit testing; and while it can be used for other kinds of tests, it won't fit those as well as it does true unit tests.

    4. Re:Useless by elharo · · Score: 1

      I don't believe code does need to be refactored to make it compatible with JUnit. JUnit can and should test the API as it exists. Unit testing should not be a consideration in designing an API. Of course, if the API needs to be changed or refactored for other reasons, that's fine; but unit testing isn't one of those reasons.

      It's a common misconception that unit testing must directly access the method its testing; but this isn't the case. private and non-public methods can be throughly tested through the public methods that call those private methods. Doing this ensures that tests will mimic the way code is actually executed in a running application. It leads to more reliable, more useful tests.

    5. Re:Useless by MSBob · · Score: 1

      A classic case of code that needs JUnit specific refactoring is most code using 3rd party APIs. You are either forced to mock interactions with 3rd party objects or set up a complex environment (which is a bit of admiting defeat as unit testing impllies your code should be tested in isolation) or break up your code along weird boundaries where you wrap 3rd party objects in your own classes just so that they are easier to mock. All of these approaches are short of ideal and there are projects to address this, among them MockObjects and JMock, but I believe none of them got it right. My idea for AOP aided unit testing should overcome these problems but I don't have the time to work on it now.

      --
      Your pizza just the way you ought to have it.
    6. Re:Useless by elharo · · Score: 1

      I don't believe that code using 3rd party APIs requires either setting up a complex environment or mocking things out. And I see no reason the code should be tested in isolation of third party APIs. If the code uses the third party APIs, so should the tests.

      I routinely write tests that access various external APIs such as SAX, DOM, and QuickTime for Java. Some of the time what I'm testing for are workarounds for bugs in specific third party APIs. Perhaps some third party APIs require complex setup (DOM isn't trivial) but that's what fixtures are for.

      Really the question of 3rd part APIs is completely orthogonal to the question of complex setup. Some APIs have complex setup. Some don't. Some APIs are third party. Some aren't. And these come in all combinations and flavors.

      There are times mock objects are appropriate. I don't want my database tests to affect the production server; but maybe I do want them to hit a real database, not some pseudo thing that doesn't behave like a real database behaves. I want my tests to tell me as much as possible about how my code will operate under real conditions. The more I mock out, the less confidence I have that code works when it has to run in the real world instead of the mock world I've invented.

    7. Re:Useless by MSBob · · Score: 1
      But then don't claim that you're unit testing. You're simply creating automated acceptance tests. The idea of unit testing as described by the authors of JUnit is to test individual methods in isolation so that their behaviour is completely predictable, understood and exhaustively tested for all possible paths. Integration testing or acceptance testing comes later in the development cycle and confusing it with unit testing is a no-no in the XP/agile world.

      Take your database example. In my experience using a real prepopulated DB tests a very small subset of data inputs and you lose the advantage of testing exhaustively all possible code paths, and your test tends to be more indicative of whether you can successfully connect to a database than whether the logic of your method is verifiably predictable and correct.

      Building a dataset where you have thousands of different database dumps to test all corner cases is daunting and unrealistic as such unit testing would take hours to run between prepopulating the rdbms, connecting to it, running a test, tearing down the database, repopulating with a different data set, running the next test and so on.

      I know where you're coming from. I've been there and I know you're getting some value out of your testing, but I suspect that like me, your tests are nowhere near exhaustive enough and tend to verify system connection points more than they verify code logic.

      For proper unit testing (it's in the name) your methods MUST run in this artificially mocked constellation of peer objects in order to exercise a huge amount of different inputs, including the ones that are very improbable.

      --
      Your pizza just the way you ought to have it.
  28. Your not the only one by sideshow · · Score: 3, Funny
    Maybe I am the only one that understands this too... J-J-J... J UNIT!


    Envy me, I'm programming's MVP!

    --

    Hollow words will burn and hollow men will burn.

    1. Re:Your not the only one by Anonymous Coward · · Score: 0

      Dont you mean "a Microsoft MVP"?

    2. Re:Your not the only one by meadowsp · · Score: 2, Funny

      MVC surely?

  29. Americana by Trejkaz · · Score: 1

    ...especially when spelled with a "z" instead of the proper "s"...

    --
    Karma: It's all a bunch of tree-huggin' hippy crap!
    1. Re:Americana by Anonymous Coward · · Score: 0

      Not a problem according to the Oxford English Dictionary.

    2. Re:Americana by The+Mayor · · Score: 1

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

      --
      --Be human.
    3. Re:Americana by Trejkaz · · Score: 1

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

      --
      Karma: It's all a bunch of tree-huggin' hippy crap!
  30. Unit tests are becoming irrelevant by JSR+$FDED · · Score: 1

    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
    http://beust.com/weblog/archives/000319.html

    1. Re:Unit tests are becoming irrelevant by CryBaby · · Score: 1

      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?

  31. Re:JUnit4 by Anonymous Coward · · Score: 0

    Probably because it was done quite a few times before the parent... by then it starts getting old.

    Hell, before I clicked on the story I thought of "j-j-j-jay unit!" ... too cliche.

    Deserves "Cliche" mod.

  32. I'm opposed to Unit Testing by Catamaran · · Score: 2, Insightful
    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 pure crap, but the system testing was thorough and the customers loved the product.

    --
    Test 1 2 3 4
    1. Re:I'm opposed to Unit Testing by willCode4Beer.com · · Score: 1

      software was just pure crap
      the customers loved the product

      You call a thoroughly tested piece of software loved by its customers crap?
      Do you work at Microsoft where buggy, hated sofware is called high quality?

      --
      ----- If communism is a system where the government owns business, what do you call a system where business owns govern
  33. Re:I don't know if I am the only one thinking this by Anonymous Coward · · Score: 0

    CLIQUE, not CLICK. It's a FRENCH WORD. Y'know, the PUSSIES.

  34. been there, done that by vidnet · · Score: 2, Informative
    simplify testing by exploiting Java 5's annotation feature

    Like JTiger has done for ages?

    1. Re:been there, done that by blue+trane · · Score: 1

      I second the recommendation of JTiger. The author provides support on freenode #jtiger too.

    2. Re:been there, done that by Anonymous Coward · · Score: 0

      No, like NUnit has done in the .NET world for years. (You know, the platform where Sun got the idea for annotation from in the first place.)

    3. Re:been there, done that by Decaff · · Score: 1

      No, like NUnit has done in the .NET world for years. (You know, the platform where Sun got the idea for annotation from in the first place.)

      Java has had Javadoc annotations for years before .Net even existed.

    4. Re:been there, done that by julesh · · Score: 1

      But Javadoc annotations are a completely different concept: other than @deprecated, they don't affect the generated class file, so you cannot use them for runtime processing of the class.

    5. Re:been there, done that by StrawberryFrog · · Score: 1

      So? .Net has those XML comments too, it's not the same thing. .Net was the first with attribute-based user-extensible run-time metadata.

      --

      My Karma: ran over your Dogma
      StrawberryFrog

  35. Why not just use TestNG? by CryBaby · · Score: 4, Informative

    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.

    1. Re:Why not just use TestNG? by chez69 · · Score: 2, Insightful

      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!

      --
      PHP is the solution of choice for relaying mysql errors to web users.
    2. Re:Why not just use TestNG? by CryBaby · · Score: 1

      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 practice there's not really any way to avoid it. To me, the things you have to do in TestNG's config file are the types of things that do make sense to put in XML: high level, structural and minimal meta information that is highly subject to change.

      I highly recommend at least reading some of the articles about it before passing judgement. On the other hand, if you've never run into any limitations with JUnit, I guess there's no reason to waste your time.

    3. Re:Why not just use TestNG? by chez69 · · Score: 1

      although I've run into some annoyances with junit, I've done my best to campaign for testable code at work. too bad nobody wants to write it.

      --
      PHP is the solution of choice for relaying mysql errors to web users.
  36. JTiger is better by Anonymous Coward · · Score: 0

    http://www.jtiger.org/

  37. Annotations use reflection, yes? by bearclaw · · Score: 1

    Don't annotations use reflection?

    --
    -- bearclaw
    1. Re:Annotations use reflection, yes? by Anonymous Coward · · Score: 0

      Although your question leaves room for... well, any answer I think I guess you mean something like "I have to use reflection to retrieve an annotation of a method/class/..., right?" or "Do I have to use reflection to find all methods with this and that annotation?"

      The answer is "yes". As well as I have to use reflection to find all methods beginning with "test" in a class extending TestCase. So, no real difference between JUnit 3 and 4 in that respect.

  38. mock objects by willCode4Beer.com · · Score: 2, Interesting

    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
  39. Check this paper by gustgr · · Score: 4, Interesting

    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

    1. Re:Check this paper by Anonymous Coward · · Score: 0

      Is this tool released to the public anywhere?

  40. Bug or feature in firefox? by Anonymous Coward · · Score: 0

    If I browse to the Junit page and then click on the 'JUnit' link, then the 'back' button will not return me to the 'Junit' page.

    Presumably this is because the 'JUnit' page replaces the 'Junit' page in my history (or something like that).

    This is not the behavior I would expect, but maybe it's supposed to work this way..?

  41. Try Selenium by TerrapinOrange · · Score: 1

    A testing framework for webapps that runs in the browser. It's both slick and simple.

    http://selenium.thoughtworks.com/index.html

  42. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  43. pre-junit by willCode4Beer.com · · Score: 1

    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, clean, and maintainable. If that makes it easier to test, then all the better.
    I think when they say refactor to JUnit they really mean that its better to refactor to make the code simpler and cleaner than to not refactor at all.

    --
    ----- If communism is a system where the government owns business, what do you call a system where business owns govern
  44. Re:I don't know if I am the only one thinking this by Narcissus · · Score: 1

    Don't know about you, but (not having actually heard the line, and only reading it here) "G-G-G-G-G-G-UNIT" sounds like a poor take on "T-U-R-T-L-E-Power"...

  45. Another article for german-capable readers by okock · · Score: 1

    If you are able to read german (or your coworkers are) - Frank Westphal has already written a good comparison for JUnit 3.8 and 4.0 at http://www.frankwestphal.de/JUnit4.0.html. You might want to try this.

  46. Actually.... by unDees · · Score: 1

    It can be quite useful to test GUIs from an automated suite. Checking for the pixel-perfect layout is less common, but if the UI spec says, "the graph is above the table," that's relatively easy to check.

    What's more helpful is checking things like, "pressing the Foo button results in the Baz dialog appearing." A good automated suite finds the Foo button by caption/control ID/window class/etc., rather than by pixel location. A better automated suite makes it easy to write your test scripts as abstractions, so instead of:

    window.find_button('Foo').push; ui.type_text('42')

    you can write your own DSL for testing:

    app.set_foo('42')

    I tend to lump these kinds of tests into the "functional" rather than "unit" category, but maybe that's just me.

    --
    "I call a baby goat a 'goatse.'" -- my non-Internet-savvy 6-year-old stepdaughter
  47. Whoops -- left on the false Grail by unDees · · Score: 1

    I've done the record/playback thing before, but those tools (good though they are) aren't able to determine intent. What did it mean when I clicked at location (267, 121) and then waited 2417 milliseconds before moving the mouse? And you still have to add pass/fail criteria. Some recording tools simply produce a giant "data dump," in which it's very hard to find where to put your asserts().

    One advantage of simply sitting down and writing your GUI test scripts is that you can start from the requirements doc while the app guys are still coding the application you'll be testing.

    --
    "I call a baby goat a 'goatse.'" -- my non-Internet-savvy 6-year-old stepdaughter