Agile Development without writing Unit Tests

Just about every Hiring Manager I have ever interviewed with has had people on staff who felt Unit Testing was required.

What if Unit Testing is not required for Agile Development ?

Let’s consider the kind of programming patterns one cannot Unit Test before moving along to the core of this topic.

  • GUI interactions cannot be Unit Tested.
    • Whether or not an event handler for a button click works cannot be Unit Tested.
  • Human Factors cannot be Unit Tested.
    • Ease of Use cannot be Unit Tested.
    • Colors and Style sheets cannot be Unit Tested.
  • Cannot Unit Test JavaScript tied to event handlers for GUI elements.

Unit Testing takes time away from the real thing your developers should be doing.

Your developers should be focusing on getting their jobs done so that the project works.

Far too often when people are required to write some kind of code coverage or Unit Test they will fake it rather than not.

Case in point, SalesForce.com requires code coverage for Apex code one wishes to run on the force.com platform. So what do people do to satisfy the system ?  They fake it.  They whip-up some fake data to drive the code coverage processor to ensure they can upload their code to Production.  You see, it is easier to fake it then spend all that time to do the right thing and completely test one’s code with some kind of Unit Test.  This is simply human nature at work.

What is even more subtle than how human nature works for those who write Unit Test code is the fact that if a programmer is confused about how his or her code works when the code was originally written then the Unit Test code will also be confused.  I mean, I know 1 + 1 should equal 2 and when the expected results do not happen for me I may wish to tweak the code to make sure the code works.  This is what programmers do anyway, right ?   Sure it is.  There is value in testing one’s code with enough conditions to uncover enough boundary conditions where the code might fail however for some problems the edge conditions or boundary conditions are very large as compared with the nominal conditions under which the code may be required to work.

The real skill your programmers should be able to master is knowing how to write code that works regardless of the inputs being fed to the code.

Nobody I know has ever written a Unit Test that ensures their code will work regardless of the inputs to their programs.

How can any programmer know what may cause his or her code to break ?!?  This requires experience.

You cannot hope programmers with insufficient experience to produce robust working code unless they have seen coding patterns that do not work.  If I know I have to write a Unit Test for every line of code I have written then I just may be able to successfully write a Unit Test that shows my code works without so much as having written good code in the first place.

But again let’s keep in mind nobody can write a Unit Test to ensure the GUI works or that real human beings will want to spend their time using the software at-all.  The greatest part of the code being written will be GUI based or why bothers with the code at-all ?!?

The bottom line is one cannot hope to be able to Unit Test for conditions one cannot imagine may happen when the code is being used by real live users.

There is no substitute for experience.

If you have the experience to Unit Test using real values that might happen under real conditions then there is no need to do the Unit Testing because the code would have been crafted correctly in the first place.

Unit Test code takes time away from more productive uses of ones time.

Unit Tests can provide a false sense of security for those who rely upon Unit Tests far too much.

Unit Tests cannot hope to test human interactions.

Unit Test cannot hope to test look and feel issues.

This work was done without the use of Unit Tests:

Agile Method Produces 442,255 lines of code in 24 months

The 122,241 lines of code that were forged from the 422,255 lines of code were tested in a variety of ways using real conditions of use but no Unit Testing was ever done on any of this code.  All this code was produced using Agile Methods with little time spent not writing code.  The person who wrote all this code had more than 34 years of programming experience spread across a wide variety of languages and operating systems for numerous projects.  After a while one just learns how to write code that works.

After all, there is NO substitute for experience.

Advertisements

About Ray C Horn
See my profile at http://www.linkedin.com/in/raychorn with more than 1286+ connections and growing all the time.

Comments are closed.

%d bloggers like this: