Explain Test-Driven Development Cycle?

Test driven development or TDD is considered to one of the most effective as well as efficient software development methodology or process that is often cited under the category of the agile software development processes.

The term “test driven development” is self justifying as one make out from the term itself that it is driven by the tests. Actually, the test driven development process is wholly based up on the repetition process of the several development cycles that are shorter than the usual development cycles. 

This whole article is dedicated to the discussion regarding the test driven development cycle. 

What are the steps in TDD process?

Test driven development process involves the below mentioned steps:

1. First step involves the creation of an automatic test case that is failing and defines a new function or some desired improvement in the code.

2. Second step involves the production of code which can pass the test.

3. Third and the final step involves the re-factoring of the new code in order to meet the prescribed standards.

This development strategy or process was introduced in the year of 2003 by Kent beck. The first programming concepts of the extreme programming or XP are considered to be related to the concepts of the test driven development to some extent.

But, nowadays the test driven development has been observed to be an individual development methodology with its own rules and independent procedures. The test driven development process has proved to be successful in improving and debugging legacy code that has been developed using the older development techniques. 

We all know that every development process has its own requirements so here in this the requirements are the automated unit tests that provide a definition of the code requirements and create the associated code themselves. 

Test Driven Development Cycle

Now let us describe the test driven development cycle in detail and sequence:

1. Adding of a test: 

- In test driven development, for every feature to be added, first a test is written that is inevitably expected to fail since it is written before the actual implementation of the features. 

- If the test does not fail, then there are two probabilities: the test is either wrongly formulated or the feature for which the test has been created already exists. 

- The test should be written with utmost understanding of the specifications and requirements which can be achieved from the use cases and user stories. 

- An already existing test can also be modified.

- Writing unit tests before the implementation of the feature helps the software developer or program focus up on the requirements before the actual code is written. 

- This feature of the test driven development differentiates it from the others and leaves a subtle and important effect.

2. Execution of all the tests and check if they fail: 

- This step involves the validation of the test harnesses for their proper working.

- This is done to ensure that no test passes mistakenly without requirement of new code. 

- The test itself is also tested but in the negative so that all the possibilities of passing of the new test are ruled out making it worthless.

3. Production of code: 

- This step involves the production of code by virtue of which the test will pass.

- The code even if its no perfect is accepted since later it can be improved.

4. Execution of the automated tests: 

After all the tests have passed, the developer can be confident that the code is perfect.

5. Refactorization of the code: 

This involves clean up drive of the code and the tests can be re- executed in order to ensure that the existing code is not being damaged.

6. Repetition: 

This involves repetitions of the whole development cycle in order to improve functionality. 

Introduction to Unified Process - Different stages in Unified Process

The Unified Process is a use-case driven, architecture-centric, iterative and incremental software process designed as a framework for UML methods and tools. The Unified Process is an incremental model in which five phases are identified:

- Inception Phase
It encompasses both customer communication and planning activities and emphasizes the development and refinement of use cases as a primary model. Incremental nature of the ensuing project is developed. In general, a use-case describes a sequence of actions that are performed by an actor as the actor interacts with software.

- Elaboration Phase
It encompasses the customer communication and modeling activities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. Elaboration refines and expands the preliminary use cases that were developed as part of inception phase and expands the architectural representation to include five different views of software - use case model, analysis model, design model, implementation model and deployment model.

- Construction Phase
It refines and then translates the design model into implemented software components. To accomplish this, analysis and design models started during elaboration phase are completed to reflect the final version of software increment.

- Transition Phase
It transfers the software from the developer to the end user for beta testing and acceptance. The software team creates the necessary support information that is required for release. At the end of this phase, the software increment becomes a reusable software release.

- Production Phase
In this, it is an on-going monitoring and support are conducted. This phase coincides with the deployment activity of generic process.

It is possible that work may have already begun on next software increment at the same time when the construction, transition, and production phases are conducted.

What is the purpose of load tests?

The purpose of any load test should be clearly understood and documented. A load test usually fits into one of the following categories:
- Quantification of risks :
Determine, through formal testing, the likelihood that system performance will meet the formal stated performance expectations of stakeholders, such as response time requirements under given levels of load. This is traditional quality assurance(QA) type test. The load testing does not mitigate risk directly, but through identification and quantification of risk, presents tuning opportunities and an impetus for remediation that will mitigate risk.

- Determination of minimum configuration : Determine, through formal testing, the minimum configuration that will allow the system to meet the formal stated performance expectations, so that extraneous hardware, software and the associated cost of ownership can be minimized. This is a Business Technology Optimization (BTO) type test.

Basis for determining the business functions/processes to be included in a test

- High Frequency Transactions : The most frequently used transactions have the potential to impact the performance of all of the other transactions if they are not efficient.
- Critical Transactions : The more important transactions that facilitate the core objectives of the system should be included, as failure under load of these transactions has the greatest impact.
- Read Transactions : At least one READ ONLY transaction should be included, so that performance of such transactions can be differentiated from other more complex transactions.
- Update Transactions : At least one update transaction should be included so that performance of such transactions can be differentiated from other transactions.

What are Load Tests - End to End performance tests

Load Tests are end to end performance tests under anticipated production load. The objective such tests are to determine the response times for various time critical transactions and business processes and ensure that they are within documented expectations. Load tests also measures the capability of an application to function correctly under load, by measuring transaction pass/fail/error rates. An important variation of the load test is the network sensitivity test which incorporates WAN segments into a load test as most applications are deployed beyond a single LAN.

Load tests are major tests, requiring substantial input from the business, so that anticipated activity can be accurately simulated in a test environment. If the project has a pilot in production then logs from the pilot can be used to generate 'usage profiles' that can be used as part of the testing process, and can even be used to drive large portions of load test.

Load testing must be executed on today's production size database, and optionally with a projected database. If some database tables will be much larger in some months time, then load testing should also be performed against a projected database. It is important that such tests are repeatable, and give the same results for identical runs. They may need to be executed several times in the first year of wide scale deployment, to ensure that new releases and changes in database size do not push response times beyond prescribed service level agreements.