(From Office Blog, Following blog entry took place on December 13th, 2006)
(Note this is a very technical Blog entry, I don't expect all people who read this to understand it completely, which is OK)
It was not until I came into projects, I understood the concept of testing completely. Back in the academy we had a short module on “Software Testing” which covered the concepts of how software is tested, related modules were “Software Quality Management” and “Software Engineering at Cognizant” etc. These modules were apart from our core module of DotNet Technology.
In due course of the time during training, we got to write xUnit Test Cases (NUnit in mine) in excel sheets, filling out various parameters and details of the tests and if its a pass / fail etc. But I never managed to get a clear cut picture of “What is the difference in introducing Testing in a Procedure Oriented Approach and Object Oriented Approach.”
My previous encounters with programming methodologies before joining Cognizant was back in the college days when I used to do a lot of procedure oriented programming in C, everything from writing “Hello, World!” to Operating System Kernels to Virtual Machines and under these scenarios “Testing” was more like (This just a general approach),
1. Think of how the problem can be broken down into simpler functions
2. Write them or expresses them in an Algorithmic flow
3. Implement each functions in Pseudocode
4. Convert to the “Pseudocode” to the respective programming language (C in mine)
5. Run the code to get the expected output
6. If not, debug the program and run again till the expected output is achieved
Here debugging was essentially testing the workability of your code and as far as Programming Kernels and Virtual Machines go the debugging of the internal working of the systems have to be debugged manually by you using a custom made debugger preferably rather than depending on debuggers like “gdb” etc which cannot be used effectively in environments like Kernel Debugging.
During the training and back in college when introduced to the concept of “Unit Testing”, my thoughts were kind of same, “write the code” to achieve the goal and then “test the code, to see if it is doing what it is supposed to do.” When I came into projects I was assigned the task of taking a class on “NUnit” and how its used as a standard unit testing tool for DotNet Technologies. On probing further on using NUnit as a unit testing tool, I came across a page on Test Driven Development in .Net in Code Project, which explained the very idea of how one should be using Unit Tests as a trigger for writing the code and not the other way.
Now this was pretty confusing in the beginning, I mean all these days I have been doing my programming the other way around. So I dug deeper into the origins of Test Driven Development (in Wikipedia) and finally reached the concepts of “Agile Software Development Techniques” and “Extreme Programming.” Now where does all of this lead us, back in college I did a learn a bit on “Software Engineering” and during training a little more (It was a terribly boring subject for me in both places). Going through various “models” of software development “Waterfall”, “Iterative”, “Spiral” etc… the list goes on. But these model are more or less a hardcore theory approach where all these Requirements, Analysis, Design, Coding, Testing, etc come into play, but none could be visualized by me in case of a practical scenario.
Agile Software Development from where Extreme Programming methodology was derived uses the more practical attributes of these theoretical models and it was from the Chrysler C3 Project that Extreme Programming took off, Kent Beck who lead the team in the project asked the team members to tests their coded units rather than as a whole program and the framework that they developed for such unit testing (initially made in SmallTalk) was ported to Java and called JUnit and then the ideology was borrowed to NUnit. It was from here that the Test Driven Development Philosophy took off.
The basic guidelines for Test Driven Development are (from the article above)
- Write a test.
- Run the test. It fails to compile because the code you’re trying to test doesn’t even exist yet! (This is the same thing as failing.)
- Write a bare-bones stub to make the test compile.
- Run the test. It should fail. (If it doesn’t, then the test wasn’t very good.)
- Implement the code to make the test pass.
- Run the test. It should pass. (If it doesn’t, back up one step and try again.)
- Start over with a new test!
This new idea was pretty strange to me, writing a test and then coding it. I heard something like this back in the academy but I thought it was more like a theoretical approach and not a practical one, since we never did any development like this. So I decided to try it out myself and create a small sample program (I have no method to attach it as of now). Worked like a charm, fail first then make it a success.
Currently I am preparing a presentation on NUnit and Test driven philosophy based on the materials I got and will post a link as soon as it is completed. Meanwhile you can take a look at some of the good documents I got on Extreme Programming, Test Driven Development and NUnit at the bottom (I will try to find a method to attach the documents as a part of my blog, as of Now ELTs cant see these documents since their internet access is restricted).
Exteme Programming and Test Driven Development Philosophy has certainly “malloc() ed” space in my heart not only did this give me a new insight into Software Development, but it gave me a much larger and broader perspective of how Testing and Development go hand-in-hand , but my first love is and always will be into Procedure Oriented Programming especially “Systems Programming” and cannot be replaced
.
Further Reading and References: