tungwaiyip.info

home

about me

links

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

 

Sri Lanka attacks: More than 200 killed as churches and hotels targeted (21 Apr 2019)

 

Ukraine election: Comedian Zelensky wins presidency by landslide (21 Apr 2019)

 

Sudan crisis: Protesters cut ties with military council (21 Apr 2019)

 

Extinction Rebellion: Climate protesters 'making a difference' (21 Apr 2019)

 

Turkish opposition leader attacked at soldier’s funeral (21 Apr 2019)

 

Agent Orange: US to clean up toxic Vietnam War air base (20 Apr 2019)

 

SpaceX capsule suffers 'anomaly' during tests in Florida (21 Apr 2019)

 

Yellow vest protests: Paris police fire tear gas at demonstrators (20 Apr 2019)

 

Columbine survivors mark twentieth anniversary of massacre (21 Apr 2019)

 

Amir Khan beaten by Terence Crawford after low blow (21 Apr 2019)

more »

 

SF Gate

 

Smart doorbells to watch over your front stoop (21 Apr 2019)

 

Alibaba head’s remarks spark debate over China working hours (21 Apr 2019)

 

One month, 500,000 face scans: How China is using AI to profile a minority (21 Apr 2019)

 

New CEO Corie Barry to take top job at Best Buy after 2 decades (21 Apr 2019)

 

Lehman Bros., a family saga, as viewed by some who lived it (19 Apr 2019)

 

Checking on Social Security estimates is a good idea, but many people don’t do it (19 Apr 2019)

more »


Site feed Updated: 2019-Apr-21 15:00