tungwaiyip.info

home

about me

links

Media

Yucatán Photos

St Lucia Photos

Photo Album

Videos

Blog

< April 2006 >
SuMoTuWeThFrSa
       1
2 3 4 5 6 7 8
9101112131415
16171819202122
23242526272829
30      

past articles »

Click for San Francisco, California Forecast

San Francisco, USA

 

The Problem With Developer Unit Testing

It was a while back when I attended the Developer Testing Forum. The were many good presentations about what developer testing can do for us. It was closed with a captivating presentation by Kent Back. They were all good. Yet I left somewhat unsatisfied.

For one thing, most of us are already developer testing enthusiasts. It was really preaching to the converted. Most topics are rather uncontroversial. We all want more unit testing. Even pointy haired boss would say so.

The real question is, why doesn't everybody do it?

Here are a few common objections and my responses.

  1. We have no time - that's sad, and it will probably be paid later.
  2. Our software is monolithic and tightly coupled, making it unsuitable for unit testing - we know this is no way to build software, loosely couple is the way to go
  3. Unit testing is difficult

Unit testing is difficult? As a developer testing advocate, I maintain it is simple and beneficial. On the other hand there is also some difficulties I do not want to downplay. Perhaps this is the right time for me to lay them out.

1. It is hard to write program that can be controlled by another program.

It is hard enough to find programmers who can write good program that functions according to a spec. I think it is a lot harder to expect programmer to write program that be also be controlled by another program, which is what unit testing requires.

There is one class of program that can be easily controlled by another program, that is utilities. This is not surprising because by definition utilities is a small piece of code to be called by another program to carry out some functions. There is also little surprise that many literatures focus on testing utilities, which is the low hanging fruit in unit testing.

Unfortunately most of the code written are not utilities. They interact with users, read and write to the database and the disk, control the flow of other processes. They react to and change system states. Testing these code requires design and instrumentation and demand more sophistication from programmers.

2. Techniques are in its infancy and are not well publicized

Since utilities are easy to test, one thing to do is to identify logic embedded in main body of code that is better isolated into utility functions. Queuing, sorting, searching and various algorithm are everywhere. It will a big win to isolate them just by the virtue that a feature can be tested much more easily.

The point I want to make is there are techniques like above for better unit testing. But they are often in its infancy and are not well publicized. Just like good programming, good unit testing is not easy to come by.

3. Extra level of abstraction can complicates design

Since we cannot always replicate the exact context for invoking the tested code, we often parameterize the code so that we can pass in a mocked environment. For example fetch_record() may means fetch from the database in the module. But since we rather not use the database in unit testing we parameterize it to take an extra resources parameter. In runtime context it will be the database. But in unit test context it will be an artificial data source.

In some case we find the added layer of abstraction actually improve the code because it is no longer hard coded to work in a single context. On the other hand flexibility come at a cost, no matter how small it may be. Having a few configuration variables and the complexity starts to multiply.

While complex and monolithic code is obviously undesirable, how is highly flexible, highly configurable code compares to a piece small and well integrated code? When simplicity is a virtue, flexibility can be a liability.

4. Test to death

Unit testing is a key tool in agile programming. You can be bold in refactoring when there is a suite of unit tests to back you up. Ironically extensive set of unit testing can also become the cement that harden your code and make changes difficult. If you diligently add tests for every subprocess of your code, chances are a lot of them will break when you change the code. It doesn't necessary mean your code has problem, it only means you have to maintain the test code and adapt it to the new version. It is arguably more difficult than changing to code itself because first you have to distinguish between a real problem from symptoms than merely need up keeping. On one hand unit testing give you the confidence to refactor. On the other hand too detailed testing can bog you down.

Finding the right level of test that cover the function but not so rigid that it breaks easily is also an art to master.


I have cited these few problems I have experienced not to suggest developer testing is not valuable. Instead I want to bring up a discussion that there are skills and technique required for successful testing. Also many issues can be mitigated by better tools and better programming language like AOP.

2006.04.15 [] - comments

 

 

blog comments powered by Disqus

past articles »

 

BBC News

 

North Korea faces tighter sanctions under Trump strategy (26 Apr 2017)

 

Turkey suspends more than 9,000 police officers over 'Gulen links' (26 Apr 2017)

 

'Exciting' blood test spots cancer a year early (26 Apr 2017)

 

Trump seeks tax windfall for business (26 Apr 2017)

 

Missing Taiwanese trekker found in Himalayas after 47 days (26 Apr 2017)

 

White Bengal tiger cub quadruplets at Austria zoo (26 Apr 2017)

 

France election: Macron heckled by pro-Le Pen workers (26 Apr 2017)

 

Trump 'considering draft order to scrap Nafta' (26 Apr 2017)

 

IS conflict: Iraqi force 'retakes ancient city of Hatra' (26 Apr 2017)

 

Ann Coulter's Berkeley speech cancelled a day beforehand (26 Apr 2017)

more »

 

SF Gate

 

Bay Area News (7 Jan 2012)

 

City Insider (11 Feb 2012)

 

Crime Scene (13 Feb 2012)

 

C.W Newius Column (10 Jan 2012)

 

C.W. Nevius Blog (11 Feb 2012)

 

Education News (10 Jan 2012)

 

KALW (11 Feb 2012)

 

Matier and Ross Blog (11 Feb 2012)

 

1st Twitter revenue drop since IPO, but stock rises (26 Apr 2017)

 

Thai woman has no anger toward Facebook after infant’s killing (26 Apr 2017)

 

U.S. Steel sinks; drinking to the Coup; United’s dead rabbit (26 Apr 2017)

 

Insurer Anthem hands feds deadline on crucial Obamacare subsidies (26 Apr 2017)

 

Novato oxygen tank supplier to pay .4 million settlement (26 Apr 2017)

 

Forget flying cars. Google’s Brin secretly builds an airship (26 Apr 2017)

more »

 


Site feed Updated: 2017-Apr-26 18:00