What is Test Driven Development? Is it useful? Should I and my team make use of it?
According to Wikipedia (I have edited the following paragraphs):
“Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: Requirements are turned into very specific test cases. The software is improved to pass new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements.
Kent Beck, who is credited with having developed or ‘rediscovered‘ the 
technique, stated in 2003 that TDD encourages simple designs and inspires confidence.
Test-driven development is related to the test-first programming concepts of extreme programming (XP), begun in 1999, but more recently has created more general interest in its own right”.
I learn out about test driven development (not with this specific name) in the 1980’s. At the time I was very interested in processes that would help the software development process. This happened while I was working on a couple projects that were based on very good concepts and ideas. The commercial products could have been very successful if the teams could have taken them to fruition. In these two cases, the company spent hundreds of millions of dollars and after several years and sub projects, both were canceled. I am not going to get into specifics, but lack of a software development methodology and management were the prime culprits for both failures.
During that time, I started arriving at work a couple hours early (I am a morning person) and in the solitude and peaceful environment, I started writing the beginnings of a book that contained a set of procedures that would help address the flaws that I saw with the approaches taken in both projects. I used the Apple Macintosh 128K computers at work and home to write the text (MacWrite) and draw diagrams (MacDraw). As time went by concepts and ideas started to fall in place. One day my phone rings. A headhunter suggested a position in Maryland. A few weeks later I started a new job in the East Coast. I did not have time to continue writing. Too many things to learn, architect, design and implement.
Years went by. A couple times I tried to revive the book. A couple years ago, on my last attempt, I spent time and some money to recover the manuscripts of the few Macintosh floppy disks I found. I no longer own a Macintosh that was able to read and recover such disks. Who know, I might try once again to recover the data I lost.
Enough background history. Let’s get to the point at hand. One of the 
principles which I read in the early 1980’s in academic papers and technical publications was to start writing tests before the design and implementation of features in a program or system. At the time that was quite evolutionary. Software development practices were typically following the waterfall model. After observing multiple failures with such approach, I decided to look for better ways which could eliminate the huge amount of documentation and lack of good and solid designs that could be used to develop quality software in a short period of time (in 9 to 12 months). I will not bother you here with the complete approach that I came up with, but just the value and need to use a Test Driven Development methodology. I started developing software like than in the early 1980’s and have continue to do so since then.
A couple weeks ago I was reading an article and the book “Agile Software Development Principles, Patterns, and Practices” by Robert Martin was mentioned. I logged into Amazon, ordered and an a couple days the book arrived. I have just read the first few chapters (was on holiday visiting family) but was impressed the way the author covers Testing in Chapter 4 of the book. His descriptions are simple and directly to the point. I wish I could write with such clarity.
For the people that know and have worked with me, I first want to bring up the following set of test utilities that I started and continue to update while working with the iCAS storage server:
| Utility | Use |
| testlib.exe | Test library functions and threads. |
| testsdm.exe | Test the System Disk Manager functions and threads. |
| testslm.exe | Test the System Library Manager functions and threads. |
Each utility contains several hundred tests. I always start by developing an entry before the associated feature would be designed and implemented in the actual server. I then would go back and forth 
between the test and the new feature until the feature works as expected. On most occasions, arguments may be added, removed or modified to get to a better implementation of a particular feature. In his book, Robert Martin refers to this approach as black box testing.
Following is a screen capture of the main menu for the system test library (testlib.exe):
* * * * System Distribution Library Test * * * *
1 Queue …
2 Registry Key functions.
3 Tree functions.
4 License functions.
5 DICOM functions.
6 CRL functions.
7 TIFF functions.
8 Compression and decompression functions.
9 TCP/IP Socket functions.
10 Configuration functions.
11 RTL functions.
12 FTP functions.
13 File functions.
16 Database functions.
17 Bitfile functions.
19 Connection functions.
20 SMTP functions.
22 Utility functions.
23 SNMP functions.
24 Serial port functions.
25 CIFS (Common Internet File System) functions.
26 Thread functions.
27 Interact with Bravo stackers …
32 Delete bitfiles from a disk cache …
33 Interact with the Ferret board …
34 Rebuild the SDM database using the disk cache …
35 Binary tree test functions.
36 MoveBitFile()
40 Event Notification functions.
41 TAR functions.
42 List WAR_xxx codes …
43 Encryption / Decryption functions.
44 Trie (Radix Tree) functions.
45 Recursion …
46 Factorial()
47 Fast Stack …
48 Fast Queue …
-1 QUIT
>>> selection [1]:
I have also developed dozens of programs I called Command Line Interfaces (CLI for short). The services respond to Application 
Programming Interfaces (API for short). By starting with a CLI and adding, removing and modifying arguments which in some cases have led to modifications in the actual APIs, testers and clients are able to invoke them from a shell programming language (e.g., Perl) to build acceptance tests. I believe Robert Martin calls such approach white box testing in his book.
Following is a screen capture of the help screen for the casping.exe CLI:
C:\> casping -?
casping [iCAS TCP/IP]
This command issues a “ping” to the specified iCAS.
To determine connectivity to a storage server one should first try the TCP/IP ping utility.
This may or may not work if the computer hosting the storage server has “ping” disabled.
To determine connectivity at the storage server (application) level one should use the casping CLI.
-a <ACCESS code>
-d <DELAY in seconds>
-h display this HELP screen
-i send an ICMP packet to the computer hosting the storage server
-p <storage server PORT>
-s <storage server TCP/IP>
-t TESTING ONLY – casping CLI hungs
-u <USER name>
-v run this command in VERBOSE mode
After reading the first few chapters, I am compelled to encourage people involved in software development to get a copy of the book. If you do so, take a look at the chapter on testing and let me know your thoughts regarding the parallels that I have drawn with the test utilities and the CLIs.
If you have comments or questions regarding this or any other entry in this blog, please do not hesitate and send me an email with your thoughts. I will keep your name in confidence unless you explicitly state so.
John
John.canessa@gmail.com
Follow me on Twitter: @john-canessa