Never been to DZone Snippets before?

Snippets is a public source code repository. Easily build up your personal collection of code snippets, categorize them with tags / keywords, and share them with the world

About this user

http://www.hrum.org http://debedb.blogspot.com/

« Newer Snippets
Older Snippets »
Showing 1-2 of 2 total  RSS 

Converting file list into a class list

Converting file list into a class list - this is particularly useful for include-classes attribute of compc task in Flex, but may be useful for Java. The <chainmapper> is most probably pleonastic but it works for me this way, and I don't feel like trying it without it...

   1  
   2     <path id="xmlrpc_class_list_1">
   3        <fileset dir="${user.dir}/xmlrpc">
   4           <include name="com/mattism/**"/>
   5           <exclude name="**/Test*"/>
   6        </fileset>
   7     </path>
   8     <pathconvert 
   9        property="xmlrpc_class_list_2" 
  10        pathsep=" " 
  11        dirsep="." 
  12        refid="xmlrpc_class_list_1">
  13        <map from="${user.dir}/xmlrpc/" to=""/>
  14        <mapper>
  15           <chainedmapper>
  16              <globmapper from="*.as" to="*"/>
  17           </chainedmapper>
  18        </mapper>
  19  </pathconvert>

JUnit: Convenient use of TestSuite based on parameterized TestCases

Here's a frequently (at least for me) occurring problem: let's say
you have a TestCase where each testXXX() method really does mostly
the same thing, parameterized by some instance variables. For instance,
I have a file consisting of good data for each parameter, such as:

   1  
   2  goodAAA=foo
   3  goodBBB=bar
   4  goodCCC=baz
   5  ...


You don't want to create tens or hundreds of methods (testAAA(),
testBBB(), etc.) by copying and pasting. So you create a TestCase that
has:

- An field called, say, key

- A single testKey() method that, based on the
key, gets the good data, gets the test data and compares them.

- static suite() method that, in a loop, creates instances of your
TestCase and sets their keys appropriately.

This is all well and good. But when you run it, a failure will always
show up in testKey() method in JUnit's UI. (Sure, you can add a message
that shows the key for which it failed, but it does not give
you an at-a-glance feedback.)

So for convenience, you override getName() to return key. Now
it's very easy to tell, by merely glancing at that JUnit bar, what
failed.

But if you run it within IDE, say, Eclipse, you want to click on the
failed test so that Failure Trace appears, where you can click on any
Stack Trace Element and get to the exact line of failure in your code.
But because the failed test's name is based on the key field, it does
not correspond to a real testXXX() method in your TestCase. So your
IDE can't take you to the code that failed.

Here's how to override getName() to get the best of both worlds:

   1  
   2  public String getName() {
   3      StackTraceElement[] st = new Throwable().getStackTrace();
   4      if (st.length < 4 || !st[3].getMethodName().equals("endTest")) {
   5          return key; 	  // Meaningful name to appear in the bar
   6      } else {
   7          return "testKey"; // Real method name to appear in Failure Trace
   8      }
   9  }

« Newer Snippets
Older Snippets »
Showing 1-2 of 2 total  RSS