Test Driven Development (TDD) Practice - An Effective Software Development-Test Style

TDD - Test Driven Development is where automated Test Cases are written before even writing the actual code. Once the test cases are written the actual minimal code is written just to pass the test case. TDD puts the software test focused before coding and enables to write ONLY testable code. This style of software development makes developers think about the kind of interface that is needed and what are the method parameters before even writing the functional code. Usually in TDD, automated unit test cases are written, however, this can be extended for integration test cases also. Understanding the interface well ahead helps to tackle the Developer Integration Test (DIT) challenges. Following are certain facts, best practices for people who are willing to follow TDD.

It’s not mandatory to automate all the test cases using a single tool in Test Driven Development Approach. And it may not necessarily be for example JUnit Java. It can be any testing tool XUnit or any UI automated test framework such as Eggplant.

Test Driven Development gives a high confidence for the developers during the code refactoring. Code refactoring activity as riskier operation when there are no automated test cases because during refactoring every time there is a code change, that needs to be tested first to ensure it works and does not break any of the other software functionality before continuing with further code refactoring.

To begin with TDD, the best practice is to write test case to test the smallest possible chunk of software functionality. Writing test cases for a larger functionality is discouraged. Automate the software builds using tools such as Hudson, Jenkins that will execute the automated test suites and report build success or failure that includes the result of test case execution results. Its a best practice to gather as a team and discuss the various module interactions before starting to write the automated test cases which helps resolve the developer integration tests.

TDD is a challenge and requires lot of encouragement especially for the team which not got used this methodology and not the team wants to follow. The benefits/advantages have to be thoroughly discussed and realized and these realizations are most of the times inspiration for following the Test Driven Development. It’s also said that developers following TDD are more productive than developers who follow traditional way of software development.

Design By Contract Principle

( Fundamental design principles continued from previous post...)

 DESIGN BY CONTRACT (DBC):  This principle talks about how elements of software collaborate with each other. In a typical complex software, first the contracts are defined and then different components of the software that need to talk to each other are defined. Typically the contracts are defined by system architect who understands the entire software system and knows how should each software components interact. In Java programming language, the contracts are nothing but the Interfaces.

Lets see what will be the consequence of not designing by contract. If contracts are not well or completely defined or not defined at all, developer integration is going to be a nightmare and will lead to schedule risk. Because during DIT (Developer Integration Testing), the developers need to talk to all other developers who are developing different components of the same system and correct the contracts. Individually developed components will not collaborate well. This needs to be avoided.

Eiffel Programming Language is one language that follows design by contract principle and a good example for DBC principle, we may want to have a look at this language.Some real time contracts are as follows

1. Device Drivers
2. Standards and Protocols
3. COM (Component Object Model)
4. SOA (Service Oriented Architecture)

A real time example for design by contract is employee and employer systems. Employe signs an agreement before taking up an appointment latter of the employer and both the parties must adhere to what was signed in the agreement in other words a contract.

MINIMIZING THE IMPACT OF CHANGE

This principle says "Keep the Software Soft", Have you seen the software system where if you modify a line of code and you assume your modification works well, but in-fact, it has broken several software functionality? If the answer is yes, then probably the software system is not following this principle.This typically happens if software grows over the time, because the software design degrades over the period of time. The principle of Minimizing The Impact Of Change talks about how we can avoid these situations and we are encouraged to apply the following guidelines for minimizing the impact of change

1. Isolate Code: Isolate the code that has the one responsibility, meaning that the code responsible for a given task has to be in one place and should not scattered in several files. Its so obvious that this practice reduces impact of change since any change in that particular task can be done in one place. As par as the impacts are concerned, you need to test only isolated code.

2. Minimize Dependencies: Dependencies are another hurdle in software development. Changing something in software component will require change in its dependent components also. And hence dependencies need to be reduced and a complete functionality needs to be implemented  by one component that does not depend on any other for completing the given functionality. In software systems, the dependencies can't be avoided 100%, however the dependencies must be in such a way that modifying a component should not require change in its dependency or recompiling the dependency. An example is that develop reusable core software components and use in required components. the core components are built, tested once and they do not require any change further Maintain unidirectional dependencies and avoid circular ones..

3. Standardize/Define Contracts: Defining contracts is a kind of standardizing how different software components must behave. However tricky part is modifying a contract needs to be done carefully. Do not just add a public method in the interface without giving a thorough thought since you are modifying the initial agreement.

4.Reuse - Don't Reinvent: Reuse as much as possible and avoid duplicates in the software code. Duplicate code always has the change impact since the person who is changing the code tends to forget to change in several other duplicated code.

5. Continuous Verification (Fail Fast): Use assertions, automated tests for continuous verification, Run automated test cases after each change.  Another best practice is to use Test Driven Development (TDD) for continuous verification purposes