Andreas Schaefer's Blog

jUnit to the Rescue

I was just recently faced with taunting task to revamping the transaction handling of the J2EE server without breaking it but improving performance and removing any resource leaks. Already two developers tried to do this but had problems to understand the existing code in the first place and so I failed, too. If we could not improve the code we had to dump the implementation and start all over again. Now just a few weeks before shipping I had to rewrite a central component without wasting other developer�s time and/or delaying the project. Lucky me jUnit came to the rescue. Instead of just starting to write a new implementation and then testing it I decided to write a test suite around the currently working code, replace the code and rerun the test suite ensuring that I did not break anything. Finally I had a chance to use test driven development (TDD).

As easy this sounds as difficult it was to implement. I spent around the same time for writing the test suite that to rewrite the transaction code but at the end testing was a breeze. The first hurtle was to decide how to test a transaction implementation because I did not want to rely on a DB, JMS etc and their side effects. So I wrote a fake XA resource that used JMS without transactions to trace the interactions with the transactions, various EJBs and 100+ tests. The first benefit from writing the test suite were a much better understanding of the transaction handling and its interaction with XA resources. At the end testing the new code was easy, straight forward and I missed one bug so far. The tests also made me very confident to put the code in the release branch without fearing to work on weekends just to fix undetected bugs.

So I have to give jUnit and TDD two thumbs up and see a beautiful friendship in the future. Nevertheless I have two little requests to the jUnit folks:

1. A way to write a message to the output file on a per test basis in order to write a description or other information out that later can be read and incorporate in a test suite report.
2. Currently there is only a successful or failed (failure or error) test result possible but sometimes it would be nice to keep non-crucial failures available but they should not fail the test suite. These warnings could be reported and even have a stack trace but would be considered a success. Examples of a warning could be a bug in a particular JDK or third party library that needs a work around but as soon as this is fixed the workaround should be removed or bugs that are postponed etc.

Comments

• on those two points...
  > A way to write a message to the output file
  I'm curious what you'd need this for in addition to being able to write a description for each assert call?

  > sometimes it would be nice to keep non-crucial
  > failures available but they should not fail the test
  > suite.
  This sounds like the best approach is to use logging to record these "optional failures", but not call fail or assert* methods on the conditions.

  I use log4j in my code, so I also use it in my tests. That way I can trace the entire flow.

  Posted by: brettporter on October 13, 2003 at 04:10 PM

• You aren't gonna need it
  As far as point 2 goes, I think this illustrates one of the other aspects of XP that Junit and Test Driven Development espouse: only code what you need to code to make your application work _right now_.

  A workaround for a feature of a particular JDK is code. You need it to make your application work. Consequently, there should be a test for it, and if the code doesn't work the test should fail. You also need to ensure that your JDK-specific code works with other versions of the JDK, unless you are running version-specific branches of the code. So again, you need a test that fails.

  By all means keep a design log with a note of things that may need to be revisited in a future date but don't twist your tests to incorporate such things. Never code your application in anticipation of future events. It's almost always wasted effort.

  Besides, I think a feature that can fail without any impact on the application is what Kent Beck calls a "code smell". If it does matter whether it works, what the heck is the point of it?

  Cheers, APC

  Posted by: apclarke on October 14, 2003 at 01:41 AM

• Outputs
  For both points 1 & 2. Log it, right?
  Using log4j or the jdk logger it should be really easy to have a "test" logging destination and filter that output to a unique file. Just look at when all is done. No problems.

  Posted by: jreed on October 14, 2003 at 07:53 AM

• Why I do not want to use Logging
  Hi Geeks

  Thank you for your replies and I just want to clarify why I do not want to use log to report description and warnings. Both are only visible to the one running the system except the log file is made available the same way as the report.
  What I want is to have a self-containing report that tells me what the test is all about, what is expect and maybe what could cause an assertion to fail. This makes it possible for anyone reading the report to see what is going on.
  For the warning it is nearly the same thing because I want to pointed to a problem from the report so that any manager or QA staff can follow such warnings without using additional tools.

  -Andy

  BTW I had extended the jUnit code therefore that it allows me to add descriptions and also to report a warning that is printed on the report (HTML).

  Posted by: schaefa on October 14, 2003 at 11:24 AM

• I don't think so
  In a perfect world this may apply but unfortunately we are not near of that. Any code does smell no matter how many tests you write it will contain bugs. Based on my experience with JBoss and other projects you are going to write workarounds and they will stick around for quite a long time. Also you may have tests you wrote but you are not able to fix the code behind it because of many constraints (time, money, leaving project members etc).

  1) I only wite code to make my application work now but what if code become obsolete but is still referenced by components you cannot control. Code is not only writen but also has to be maintained and my arguments are more about that.

  2) When I start to let my tests fails I will have problems to manage them in the future. The only good way to manage them is to have no bugs. If I am forced to let a test fail I guess it is much better to keep it as a warning stating the problem and the reasons why it is not fixed.

  3) I do not want to rely on future events but keep an eye on known problems and track them. A log is bad substitute because it separates it from the jUnit report and so it prevents everyone from tracking the warnings.

  4) The point is that there is more between heaven and earth than just a successful or failed test. Code is not only written but must also be maintained and improved afterwards.

  I have problems to understand how jUnit does not even allow a description to be added to its report. As you can read in Mike Clark's recent blogs he does not know sometimes why a test was done this way and I had similar experiences and this should not happens. Like JavaDoc provides a description that comes with the source code jUnit should allow a description that comes with the report.
  I am still convienced that a warning or pending problem state would be a good thing because it does allow to keep a problem on the radar without loosing a grip on the current failed tests. Code is always fishy and it is only a question of that a certain test is writen or now but no test is not an option for me. I rather have a warning that no test.

  -Andy

  Posted by: schaefa on October 14, 2003 at 11:50 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling3 on December 13, 2007 at 06:02 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  网络营销软件
  网站推广软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版

  Posted by: uuok999 on December 20, 2007 at 12:22 AM

This work is licensed under a Creative Commons License.