Can Test Driven Development (TDD) work for data-oriented development?

Today the test driven development is quite a familiar concept among the developers and testers in the field of software engineering and technology and so is the data oriented development. 

Data oriented development is commonly known as the object oriented development. We have taken up an important question in this article which is “can test driven development work for data oriented development?”

But before answering this question we shall discuss about the two different developments involved in the question individually so that the understanding of the answer becomes easy. 

About Test Driven Development

First let us discuss about the test driven development. The test driven development as the term itself suggests is based up on carrying out the development process with the help of short development cycles that include the following steps:

1. Addition of a test: The development begins with the creation of test cases for all the features.
2. Execution of all tests in order to check the working of the new one.
3. Production of code implementing which the code can only pass the test and does not incorporates any new functionality.
4. Execution of the automated tests and observing their success.
5. Re-factoring or cleaning up of the code
6. Repetition of the whole cycle for the improvement of the functionalities.

Many development styles have been developed for the test driven development few of which are mentioned below:

1. YAGNI (you ain’t gonna need it),
2. KISS (keep it simple stupid),
3. Fake it till you make it and so on.

About Data Oriented Development

- It makes use of the models that are developed around the real world concepts.

- This development methodology involves the incorporation of the data behavior as well as the structure. 

- The process starts from the quantization of the data in to small distinguishable and discrete entities which are known as the “objects”. 

- Each of the objects created have their own inherent and unique identity. 

- Other characteristics of the data oriented development aare:

1. Classification
2. Inheritance
3. Polymorphism

- The essence of the object oriented development lies in the organization and identification of the application concepts.

- The primary focus lies with the analysis and design phases. 

- The data oriented development is known for encouraging the software developers to work and think. 

- This can be thought of as a conceptual process independent of a programming language. 

- The methodology here is to build the software model and add details to it during the design. 

- It consists of the following steps:

1. System conception
2. Analysis
3. System design
4. Class design and
5. Implementation

Can TDD work for Data Oriented Development

Now coming to our question, the answer is yes test driven development can absolutely work for the data oriented development since it has many characteristics and benefits that can be successfully incorporated in to the data oriented development:

1. Predictability: With the test driven development it is easy to predict that when the development process if finished since all the tests that they have are passed by the code.

2. Learning: With the test driven development the developers get a better understanding of the code and hence it becomes easier to develop the code that models the real world very well.

3. Reliability: Moreover the test driven development makes the data oriented development more reliable since it has a suite of regressions tests that cover all of the system aspects.

4. Speed: With the test driven development the data oriented development can be speeded up since a little time is spent debugging and mistakes are sought very soon.

5. Confidence

6. Cost

7. Scope limiting

8. Manageability

9. Documentation

What is the development style used in test driven development?

Several aspects, approaches and styles have been designed for carrying out the test driven development process. Adequate focus is kept on the writing of the code so that only the necessary code is produced that is required for passing the tests. Such an approach makes sure that the program designs are simple, clearer and cleaner. 

Popular aspects used in TDD

Below mentioned are few of the aspects that are quite popular among the programmers and developers using the test driven development methodology:

KISS:  

- It stands for 'Keep it Simple Stupid' and states that keeping some systems simple yields better outcomes rather than keeping them complex. 
- It defines simplicity as a key goal in the process of program designing and avoids unnecessary complexity. - Some examples of failure to follow Kiss are given by the function creep, scope creep and so on. 
- This principle of software programming was coined by Kelly Johnson.


YAGNI:  
- It stands for 'You Ain’t Gonna Need It'. 
-This though being one of the primary principles of the extreme programming is followed in the test driven development also.
- According to this principle, the functionalities should not be added until they are very much required.
- In other words, it says that the functionalities should be implemented only when they are actually needed and not merely by what one foresees. 
- This aspect has got a few drawbacks.
- The time required is obtained from the other processes like adding, testing, etc. 
- It calls for the need of debugging and documentation of the new features. 
- New features might impose certain constraints which can conflict with the working of a necessary feature in the future. 
- The program may experience the code bloat i.e., it may get bigger and complex and thus complicated. 
- A strict revision control is needed. 
- Addition of more and more features may cause snow ball effect leading to the creeping featurism.


Fake it till you make it:
- This aspect boosts the real confidence of the developers, thus preventing them from getting stuck in to their self fulfilling prophecies. 
- This technique can effectively combat the depression that most of the developers and programmers experience.

Tests are written to achieve the desired design of the software system or application whether is it advance or primitive. The code may pass all the tests being simpler as compared to the target pattern. This may sound odd at the first go but it eventually helps the developer to keep a sharp focus up on the important elements.

Whichever style is followed, there are two basic steps that should be compulsorily followed

1. First write the tests: 
It is required that the tests are written first before the functionality is actually implemented. This step is    known for having two benefits:
       (a)  It ensures that the application is worth testing i.e., it provides testability to the application. The application is considered to be tested via the outset by the developer and he/ she does not need to worry about testing later.
      (b) It ensures that every feature and functionality has a unique test developed for it so that the functionalities are tested as the executable specifications.


2. First fail the test cases: 
This step is carried out in order to ensure the correctness of the test and also its error detection ability. Once this is done, it becomes easy for the implementation of the functionality. This step is the essence of the test driven development. The following steps are constantly repeated:

(a)    Adding of tests cases that fail.

(b)   Writing ode to pass them.

(c)    Refactoring

The productivity is also enhanced following the above two steps. 

Architectural Design - Representing the System in Context and Defining Archetypes

As architectural design begins, the design should define the external entities that the software interacts with and nature of the interaction. Once the context is modeled and all external interfaces are described, the structure of the system is specified by the designer. It is done by defining and refining software components that implement the architecture.

REPRESENTING THE SYSTEM IN CONTEXT

Architectural context represents how the software interacts with entities external to its boundaries. A system context diagram accomplishes this requirement by representing the flow of information into and out of the system. At the architectural design level, a software architect uses an architectural context diagram to model the manner in which software interacts with entities external to its boundaries.

How do systems inter-operate with the target system?
Superordinate Systems
These systems use the target system as part of some higher level processing scheme.
Subordinate Systems
These systems are used by the target system and provide data or processing that are necessary to complete target system.
Peer-level Systems
These systems interact on a peer-to-peer basis.
Actors
These entities interact with the target system by producing or consuming information necessary for requisite processing.
Each of these external entities communicates with target systems through an interface.

DEFINING ARCHETYPES

Archetypes are the abstract building blocks of an architectural design. It is a class or pattern that represents a core abstraction that is critical to design of an architecture for the target system. Archetypes can be derived by examining analysis classes defined as part of analysis model.Target system architecture is composed of these archetypes which represent stable elements of the architecture. Some kind of archetypes are:
- Nodes
- Detector
- Indicator
- Controller

What are different types of architectural styles?

Large number of computer systems are created. Some of the architectural styles are:

Data Centered Architecture
Data store resides at center of architecture and is accessed frequently by other components that update, add, delete or otherwise modify data within the store. A data centered architecture promotes integrability, which means existing components can be changed and new client components added to the architecture without concern about other clients.

Data-flow Architecture
Data flow architecture is applied when input data is to be transformed through a series of computational or manipulative components into output data. Pile and filter structure has a set of components called by filters connected by pipes that transmit data from one component to another. Each filter works independently. If data flow degenerates into a single line of transforms, it is called batch sequential.

Object Oriented Architecture
In this architecture, data and operations are encapsulated by the components of a system. Communication and coordination between components is done by message passing.

Call and Return Architecture
In this architecture, software designer achieves a program structure which is relatively easy to modify and scale. Two sub-styles exist: Main program/subprogram architecture and Remote Procedure Call Architecture.

Layered Architecture
In this architecture, different layers are defined. Each layer accomplishes operations that progressively become closer to machine instruction set. Components service user interface operations at outer layer. Components perform operating system interfacing at the inner layer.