This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Running unit test cases automatically with Ant

 
Robin Clark
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been busy reading my Pragmatic Unit Testing book. I've got the following unit tests that run successfully, but I'd like to know how to automate the running of the tests cases in ant.
Here is my first unit test module:

I can run this successfully from the command line by saying:

I have a very simple build.xml file, and I think that this is what I need to do to run the test code automatically at the end of each build:

Does this look like the correct way to set it up so that my tests are run automatically at the end of each build?
 
Billybob Marshall
Ranch Hand
Posts: 202
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Get rid of the "main" method. Use the <junit> task in ant to run the test(s), rather than <java>
 
Robin Clark
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good advice. How do I make the task run automatically in ant. I changed my code and my build.xml, but I'm not sure how to make the task run. I just started looking at Ant this morning...
 
Robin Clark
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That was a dumb question. I just need to wrap the junit tasks in a <target>. Like this:

Still need to refine my junit attributes....
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't resist jumping in with a few comments; I hope you don't mind.
  • Don't hard-code data like

  • "i:\\Apps\\Apache\\Tomcat\\webapps\\robinapp\\WEB-INF\\utt\\5137233711" into your tests. How will anyone else ever be able to run these tests? A URL like this should be composed from pieces at runtime; the machine-dependent piece ought to come from a properties file.
  • Don't include redundant data in a test. This is important in normal coding, but it's even more so in testing. The string "513723" appears in several places here; put it in a String constant and reuse it. There are other, longer strings that include this as a substring; build those up with "+" using this same constant. You may have to change the test. More importantly, someone may want to read this test to help them learn about the Session class.

  •  
    Andy Hunt
    Author
    Ranch Hand
    Posts: 55
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ernest is right on the money.
     
    Robin Clark
    Ranch Hand
    Posts: 81
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I really appreciate your input. I've been struggling with unit testing issues for years. Here is the method I am testing:

    Let me tell you a bit about the Session object. It keeps track of a list of audio filenames that are in a directory. It has the following private member variables:
    uttDestination -- this is the full pathname to where the audio files are stored
    trueSpeakerStr -- string representing the 10 digit phone number of a person
    pretending to be the trueSpeaker
    sessionID -- string like "S01" that the session #
    When you put the uttDestination, the trueSpeakerStr and the sessionID together with a bit of other magic, you can re-create the full pathname of the audio file.
    Are you suggesting that instead of hard-coding these values in the test cases I should put them in a separate file and read them in?
     
    Ernest Friedman-Hill
    author and iconoclast
    Marshal
    Pie
    Posts: 24211
    35
    Chrome Eclipse IDE Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Robin Clark:

    Are you suggesting that instead of hard-coding these values in the test cases I should put them in a separate file and read them in?

    Well, perhaps not. If that's all that happens with the paths, then the actual value of the path doesn't matter. I do tend to use paths like
    "/value/doesnt/matter.txt"
    in tests to indicate this to a person reading the test. See, as I read your code, it seemed as though it meant that a complicated directory hierarchy needed to be set up to run the test.
    In any case, if Session doesn't actually create a File out of the path, and you know that when the class is changed in the future, it still won't, then there's no reason to make the path an external parameter.
    But my other point -- that the redundant strings, and the strings contained inside other strings, should be made into constants so that it's easy to see what's supposed to be equal to what -- stands.
    [ February 20, 2004: Message edited by: Ernest Friedman-Hill ]
     
    Robin Clark
    Ranch Hand
    Posts: 81
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I think that this is much nicer. Instead of hard-coding a filename that I know exists, I create a file in the setUp method and then delete it in the tearDown method. What other improvements can I make:
     
    Jeanne Boyarsky
    author & internet detective
    Marshal
    Posts: 34681
    367
    Eclipse IDE Java VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Robin,
    I would create an instance variable for file f. That way you aren't creating the file object in both the setup and tear down methods. More importantly, it is clearer that you are referring to the same file object.
    You don't really need to catch the IOException in setup. If the setup method throws an exception, the tests will automatically fail (with a message about an IO exception.) Right now, it will fail without telling you why.
    In testRetrieveUtterance(), you have assertEquals(actual, expected); It should be assertEquals(expected, actual); The error message junit gives will be clearer that way.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic