Author Archives: Jeanne Boyarsky

a response to – “What would you say is the average percentage of development time devoted to creating the unit test scripts?”

Posted on by
2

How long does it take to compile? We don’t ask that. It would be absurd. The fact that people ask how long unit testing takes mean they see it as an optional cost to be incurred. What I want to know is why they don’t ask for a similar accounting of the cost of NOT writing unit tests!

I think the “cost” of unit testing falls into three categories:
1) The early days/training/learning
2) The ongoing cost
3) The cost of not testing/cost of errors

The early days/training/learning
The first time you do something, it takes longer.  This is why we pay experienced people more. It is expected there is a training or learning cost. If an activity is worthwhile, one recoups this cost quickly.  It is called an investment.

The problem I see is that some teams don’t get past this point. They see unit testing taking longer the first time and imagine it will take that long forever. I wonder how these people learned Java or regular expressions or anything else. Except that they wanted to learn the hard tech. If one believes the current buggy state of affairs works or can’t imagine a better way, staying motivated to get over the learning hump is difficult.  This is why having a mentor or coach promoting unit testing is helpful.

The ongoing cost
When writing unit tests as part of the task, it is difficult to measure the
amount of time it takes.  I really can’t tell you what percentage of development time I spend “writing tests” because it occurs at the same time I do the other parts of the task.  I also couldn’t account for the percentages of time I spend typing, thinking, compiling, etc.  These things are occurring simultaneously.

Many of the people who complain the ongoing cost of testing is to high are treating it is a separate activity. They write the code, manually test it, debug, repeat and then write a unit test. If done that way, the entire cost of writing the test is extra. And often resented because they really are “done” before they start writing the tests.  In this case, the unit tests only have value as regression but not as part of the development process.  While I suppose it is better than nothing, I find this a way to make writing tests more costly than it should be.

I’m not saying one has to use TDD (test driven development) to see a benefit. Using the unit tests as a replacement for that manual testing lets it become a cost you need to incur anyway. Granted, it takes a little longer to write a test than test by hand. But this is minimal. It is also offset by way less regression issues and the ability to test error conditions easily. And if you write tests in close proximity to the code, it is even faster.

There’s another measurement issue going on here.  Yes, it takes longer to write tests than test manually ONCE.  If you are writing a script that will only be run once, it isn’t worth it.  How many times have you had an application that was written once and then never touched again?

The cost of not testing/cost of errors

This is the part that really bothers me.  There is a cost to not doing an activity.  It tends to be swept under the rug and treated as a cost of doing business.  It is hard to see opportunity cost.  But it still exists.  The two biggest costs I see are finding errors late and regression errors in future release.

  1. We’ve all see the curve that shows how fixing errors late is much more expensive than finding them in development.  Unfortunately, developers get to claim they are “done” when they’ve really just moved the errors to later.  They are more expensive, but the developer gets to claim they finished the task in X days.  Managers need to stop allowing this.
  2. The future release problem is even harder.  I think more of the value of having unit tests comes from the future.  Some developers claim that they don’t need unit testing because they produce high quality code without it.  Sometimes this is even true.  However, what happens when that developer looks at the code in a year or leaves the team.  The unit tests are code and live on.  My development velocity on maintenance/enhancement tasks is much higher with unit tests because I don’t have to posit what I was thinking a year ago when I wrote the code.

What if my management still needs a cost

This blog post is inspired by someone asking me this question.  “What would you say is the average percentage of development time devoted to creating the unit test scripts?”  While I take issue with the question, I think he is still going to have it.  As a result, here are links to three articles/webpages that use numbers.

  1. Misko Hevery comes up with a figure of 10% cost.  He calls it a 10% tax and points out the benefits that come a tax.  Note that he is writing tests as an integral part of his process and is fluent in doing so.  He also actively dispels the myth that testing takes twice as long.
  2. Brian Johnston discusses costs. I like that he covers the cost of not testing too.   While he picks extreme figures (based on the worst case myth), it does cover risks and things to take into account for your own shops.  Also, he discusses the hardest 15% of tests.  The earlier tests written are the easier ones and cost less.
  3. A variety of opinions wiki’d. While numbers are mentioned, the real value of the page is the caveats for dealing with such numbers.

Conclusion

When talking to management about a cost, make sure they know about the associated benefits.  And the cost of other options.  Doing nothing is an option and has a definite cost!

see part 2 of this blog post

Refactoring JUnit 3.8 to 4.0 when hierarchy extends TestCase

Posted on by
Reply

Problem:

I want to start writing tests in JUnit 4.0, but I have a lot of tests in JUnit 3.8.  I can’t just start writing tests in 4.0, because I rely on common setup/assertions in my custom superclass which extends TestCase. (Which means JUnit will only look for 3.8 style tests)

Solution:

Create one or more new classes to contain static method equivalents that you need.  The new code can use static imports to get these methods.  The original abstract class can delegate to them.

Limitations:

Some frameworks require you extend a certain class.  Until the framework provides a non-JUnit 3.8 dependency, there’s not much you can do here.  You can still use this approach for tests that don’t require that special framework.

UML for refactoring:

Sample code:

package com.javaranch.asserts;

import static com.javaranch.asserts.JavaRanchTestUtil.*;
import junit.framework.*;

public abstract class AbstractJavaRanchTestCase extends TestCase {
   @Override
   public void setUp() throws Exception {
      super.setUp();
      setUp_propertyConfiguration();
   }
}

Conclusion:

I’ve done this refactoring enough times that is second nature by now.  This blog post documents the refactoring since I’m not finding it on the web.

What other problems/sticky situations have you encountered when mixing JUnit 3.8 and 4.0 code?

javaranch forums go mobile

Posted on by
Reply

Want to know what went  on behind the scenes of JavaRanch’s mobile site creation?

Timeline

  • January 2009 – We started talking about how poorly the site renders on a BlackBerry
  • July 2009 – I got a BlackBerry for work.  And ugh.  The forums do look horrible.
  • August 2009 – Tried out BlackBerry emulator and explored the minimalistic approach possible to creating a mobile version (see next section.)  That didn’t work and I wasn’t prepared to spend a lot of time on it in the summer.
  • mid November 2009 – Start discussing design/UI.  Noted it took 4 minutes to edit a post via BlackBerry.  Very excessive.
  • late November 2009 – Restart development using approach #2.
  • December 2009 – Weekly deployments to production using “secret URL that only the moderators know” for beta testing.
  • January 3, 2010 – Mobile URL announced to public and added to e-mail notifications

Approach #1 – Mobile CSS

My original theory was that the easiest thing to do would be to just add a mobile stylesheet that would hide some columns.  It wouldn’t shrink the pages of course.  But as a first step: slow and readable beats slow and un-readable.  I quickly ran into some problems:

  1. The BlackBerry doesn’t like mobile stylesheets.  Bushido covers the options in a lot of detail.  Search for “Alright, alright. Gimme the code already!” for the ugly CSS imports.  The real problem is that you don’t have a mobile stylesheet with this technique.  You have a stylesheet that everyone uses called mobile and the main stylesheet which cancels out the main one.  Developing for this is crazy as you are compromising what stylesheets appear to do.  And it will break when RIM finally gets their act together.
  2. JForum uses a largely table based layout.  This doesn’t go well with CSS for hiding things.
  3. The table layout made changing anything incrementally very difficult.

Approach #2 – An actual mobile site

This approach is definitely more mobile friendly as the pages are designed to be mobile sized.  They are also written from scratch and get to use <div>s.  Basically what I did was take the real page, pick the most important parts and create div layouts for them.  Once I had one done, the rest followed easily.  There are a few limitations documented in the JavaRanch announcement site.  But overall, I’m happy with it.  It is certainly way better than what we had before.  And we will continue to tweak it.

Testing

I tested locally using the BlackBerry simulator and later with the Droid emulator. I also tested using my real BlackBerry after deploying to the test server.  The aggravation of using a real mobile device isn’t captured on the emulators!  It is possible to use testiphone.com as an emulator.  It is not completely accurate though.  In particular, it didn’t show the viewport problem.

<meta name=”viewport” content=”width = 320″ />

We also tested on a variety of real devices.  Many moderators tested on their personal handhelds and we got a good variety that way.

I’d like to thank a few people in particular.  Thank you to everyone who let me test on their device, especially

  1. Gregg Bolinger – for instant feedback in testing the viewport fix at 11pm on both the iPhone and the Droid.  (And more testing than anyone else.)
  2. A few coworkers (at my real job) – for the wide variety of devices I got to put my hands on.  The simulators really aren’t the same.  Five minutes on the real handheld at lunch really helped.
  3. Chuck from the NYC Spin for offering his tiny touch screen device (the smallest I’ve tested on) without my even asking!

Marketing

You know how sometimes marketing picks a ship date and it overrides “doneness” ?  Well, I really wanted to announce this on January 3rd – the one year anniversary of us being on Java based software.  There are some things that I wish were more resolved like why Google Mobilizer is injecting itself in links. Overall, I think it is in good shape and ready for people to try out though.

—

What do you think of the new site?  Share in the JavaRanch announcement thread or as a comment here!