Test Driven Development

What is so different in Test Driven Development(TDD)? Its a methodology which seems to work in reverse. That is – you write the test code, write the actual code and refactor. So, what is the advantage? We are so used to – write the code first and then write the code to test it – that this seems a bit counter intutive. But, if you think about it, it makes sense, a lot of sense. Why? Once we write the code we know what we have written and generally we tend to write to tests that seem to test what we know will work! If you reverse the method, you can think about what are the different ways the user can use your functions. This has the following benefits:

• Your functions( or APIs ) will be better since you are trying to find out how the user will use your code even before you have written your code!
• The code seems to be more robust since you are anticipating before hand what are the different ways your code can go wrong!
• It makes your code design and code better
• The test-code-refactor cycle eventually leads to better design and robust code

If you try to decipher how the user will use your code after you have written it, you will realize that the APIs you are providing are cumbersome and non-intutive. TDD will make your APIs more usable, easy to use and robust. Since you are the first user of your to be written code, you can fix some of the issue even before they occur! Why refactor is needed. Refactoring is needed since we all recognize that – doing things right the first time – works only in theory! We usually discover better way of doing things once we realize the limitations of current implementation. These limitations are called ’smells’ in the agile world. Refactoring tends to make the code more robust and easy to maintain and leads to lower life cycle costs over years.

You can use NUnit, JUnit or CPPUnit for writing your test cases before you write the test code. You can use refactoring features available in the Visual Studio or in Eclipse for carrying out the refactoring.

Improving software development productivity

Cutting down software development time and improving productivity are the most debated topics in the software industry for some time now. The industry has responded to the challenge with new technologies, different software development paradigms, different design methodologies, promoting re-use, use of COTS components rather than developing them in house etc.

The availability of new programming languages like Java, .NET etc have helped improve developer productivity significantly by providing a rich set of libraries and by providing enhanced language constructs. Availability of specialized COTS libraries have further improved productivity and they have also resulted in improved quality of products. Availability of modeling tools, Domain Specific Language(DSL) Tools, Generative Programming Techniques, Software Product Line development methodologies, Software Factory approach, availability of domain reference architectures, Design and Architectural Patterns, application frameworks etc, are some of the techniques used today for building better software systems as well as for improving development productivity.

There are lots of modeling tools available in market today. Many of them support modeling in UML. While these modeling tools allow the designer model the solution using the constructs available in UML, they have many shortcomings. The tools generate only the template code and the developer still needs to write source code manually. Another problem is, generally, the quality of generated source is not good. UML is too vast and this deters designers, programmers from using it. While the experts are of the opinion that 80% of the modeling can be accomplished by 20% of the UML constructs, there is no universal consensus on what those 20% constructs are!. Another related problem with UML is its poor semantics. Because of these and other problems, Microsoft is betting big on the software factory approach.

A software factory approach combines different concepts listed above and provides an integrated environment for software development. The concept is based on the Economy of Scope. The concept is based on the fact that- unlike in the automotive industry where millions of identical products are manufactured(aka economy of scale), the software industry needs to develop ’similar’ but distinct products( aka economy of scope). It combines various approaches – component re-use, generative programming, models, patterns etc to achieve this. Microsoft provides Domain Specific Language(DSL) Toolkit to achieve automatic artifact generation including – source code, configuration files etc. DSLs are domain specific constructs( can be built for each domain using a tool that supports meta-modeling) and do not suffer from the deficiencies of UML tools. The generative programming technique is based on the idea of software generating software i.e. source code and other artifacts from graphical models, textual specifications etc. Microsoft is providing lots of add ins to the Visual Studio for supporting the factory approach. There are also lot of commercial add-ins available from many different vendors. Eclipse is another popular platform that can be exploited for Factory based solutions. INRIA, for example, is developing add-ins called ‘Smart Tools’ that is based on the Factory approach. Eclipse is easily customizable. It is highly flexible and its superior architecture makes it a very attractive tool for Factory based development.

The software product line approach is based on the same assumptions as the factory approach. It recognizes that the products that belong to the same domain have lot of things in common. Main idea behind this is the concept of commonality and variability among different products. The development of common and variable features of products are done by disparate teams. The common features are developed by a Core team(aka Domain development team) and variable features are developed by Application development teams. The software is designed such that it behaves little differently based on different configurations.  Some of the techniques used  by the product line development projects are – configuration files, templates(aka generics), file substitutions, #ifdefs,  reflection etc. By using the same common functionality in different products helps achieve significant savings in development time and also during the maintenance.

In the future, the architect needs only to know different components, patterns etc available. He will use these predefined artifacts and mix and match artifacts and arrive at a solution without much effort. Hope that day is not too far!