An efficient software development process for software developers is crucial, it determines the development is a painful struggle, or joy progressive. Some of the recent rise of the software development process-related technology to provide some of the more efficient and practical process of software development methods. The one of the worthiest of attention is Test Driven Development.

So in this article, I will introduce what the TDD is,  comparison with other methodology, TDD’s process, TDD’s advantage and disadvantage and why we use TDD.

I hope to give an overview of exactly what test-driven development is and the conception of the test-driven development.

What is TDD

TDD is test-driven development (Test-Driven Development) abbreviation, it created by Kent Beck, with having developed or ‘rediscovered’ (L. Williams, October) the technique, is agile development of a core practices and technologies, but also a design methodology. TDD principle is prior to the development of functional code to write unit test code, test code to determine what products need to write code. Although TDD is the core practice of Agile methods, but are not suitable for XP (Extreme Programming), it can also be applied to other development methods and processes.

The basic idea is to pass the test TDD to drive the entire development proceeds, but the test-driven development is not just a simple testing, but the requirements analysis , design, quality control quantization process.

TDD is not only an important purpose test software, testing to ensure the quality of the code is only part of it, but also help customers and programmers need to remove ambiguities in the development process. TDD first consider the demand for the use (objects, functions, processes, interfaces, etc.), mainly to write test framework for process design and interface functions, and test framework can continue to be verified.

 

Traditional and Test Driven Development Compared

 

(Ambysoft, 2003)

At the following diagram shows the biggest differences between traditional and test driven development processes.

As the above diagrams show, the key difference between the two approaches is simply the test first nature of TDD. In the traditional process, you do not write your tests until after completing the full implementation. Thus, testing is primarily a verification that the code works as intended; it does not help the developer in their work. Since TDD starts with testing and incorporates testing as a part of the development process, the tests actually help the developer and will generally improve the quality and design of the code.

TDD is a programming technique originally, it indirectly makes sure your code can be unit tested thoroughly checked. However, it can do more than this. You still need to refer to some of the traditional testing such as functional testing, user acceptance testing, system integration testing, and so on.

The process of TDD

At following, I would like to describe how TDD actually works, how does a developer accept and begin to start TDD process in their work.

Step one: Write a failing test

A TDD professionals began by extracted from system requires a specific function. Once when a particular function is determined, the developers will write an automated test, for the test it will test a specific function. Developers need to create and test, after that, they will write a short code to test the code simply run. Of course, since the actual function has not been developed, the test will initial fail. The test of the initial fault is an important aspect of TDD; this is the beginning of each TDD test.

Step two: Write the code so the test passes

After a failing automated test is completed, the developer will write the code to carry out the function. When the developer works on the code, the good things is, they can implement the automated test at any time to check if their code is working. This gives the developer immediate feedback, when test failure developers have a very good opportunity to debug, they can quickly find errors and repair it. The developer continues to test their code until their automated test is passing. When the test is passing which means the code is correct, we have to say TDD is very efficient, and when the function operation successful, the developers will be more confidence at the following work.

Step three: Refactor

Refactoring is all tests have to undergo the steps; the developer had already created the code and the code needs to be refactored. To be honest, refactor not always a required; however, sometimes people always make a few mistakes more or less, after all, who can guarantee that his every decision is right. In order to prevent that mistake occurrence, so once the test is passed, the developer should go back and use a good design to properly implement the reconstruction of their code. Throughout refactoring process, developers can run and run automated tests many times to make sure they do not destroy the required functionality.

Step four: Repeat

Once the programmer has a test that is passing and they have clean and refactored code, they can then move on to the next function and proceed in the same manner. As the programmer progresses through all the required functions of the application, they will ultimately develop the actual working application. A real benefit of TDD comes with this, as they will simultaneously be completing a full test suite for the application with complete test coverage. It is very rare that a programmer will go back to their code and write tests for everything after having a fully implemented application. Complete test suite code coverage is simply a natural by-product of the TDD process and it is one that should not be underestimated.

Benefits of TDD

The benefits of using TDD are wide reaching and very compelling. In the paper Test driven development: empirical body of evidence, the following is stated, (Boehm, 1981)“TDD may help to improve software quality significantly, in terms of decreased fault rates, when employed in an industrial context.” As this article collects and summarizing 13 empirical research from industry, which is backed by facts quite a dramatic conclusion.

In an article entitled, Does Test-Driven Development Really Improve Software Design Quality, (Saiedian, 2008) the authors document how TDD contributes to better code. The article shows that code produced through TDD is generally better organized into smaller and well-designed units that are better tested. Such code not only is better from its initial release, but it is easier and less costly to maintain and adapt in the future.

Overall, you can find many articles and reports that list the many purported benefits of using a TDD process in your software development. Some of these benefits are as follows:

• Less software defects: since TDD produces code that is much more highly tested, the resulting software is normally low rate to defects.
• Fast feedback to the programmer: the feedback gave to the software developers during the TDD process in short cycle so they can respond and change the error quickly. All a developer needs to do in order to find out if their code works is just run the tests.
• Increased developers confidence: Since all the code is covered by tests that, ensure it works as expected; developers have more confidence in their own code.
• Enables refactoring: since total test coverage is needed to refactor code, by doing TDD you are creating code that can easily be refactored.
• Cleaner and simpler designs: the code produced by TDD has been shown to be generally cleaner and simpler than code produced through a more traditional method. This ultimately produces code that is easier and less expensive to maintain.
• Reduced debugging time: Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how clients (in the first case, the test cases) will use the functionality. Therefore, the programmer is only concerned with the interface and not the implementation.

Overall, these quite substantial benefits should at the very least pique the interest of developers. Embracing a TDD process does require quite a radical shift in the thinking of developers but these benefits show that the effort required to do so is likely worth it.

Disadvantage of TDD

1. Test-driven development does not perform in need all functional testing, to determine the success or failure, because of the extensive use of the unit test cases fully test. These examples are user interface, with database and some working procedure depends on the specific network configuration. TDD encourages developers to code for the minimum amount of such modules, and maximize the logic is in the test library code.
2. Management support is essential. If not the entire organization think test-driven development is to improve product, management may feel that take time to write tests was wasted.
3. High digital unit tests could lead to false sense of security, so as to reduce the additional software testing activities, such as integration testing and conformance testing.
4. Tests as part of a project maintenance overhead. Write bad tests, such as those including hard coding error string or itself is prone to failure, are maintenance is expensive. This is especially the case with fragile test. Yes, test on a regular basis to produce false failure will be ignored, therefore, when a fault occurs, the real risk it may not be able to be detected. Possible by mistake the reuse of the string to write as low, easy to maintain test, for example, it should be in the above code-refactoring phase of the target.

TDD and ATDD

TDD and ATDD

Compere with TDD, Acceptance Test Driven Development (ATDD) is a practice in which the whole team cooperation discusses acceptance criteria, with examples, and then distils them into a set of concrete acceptance tests before development begins. It is the best way to ensure that all developer have the same shared understanding of what it is their actually building. It is also the best way to ensure we have a shared definition of done.

TDD and BDD

TDD and BDD

BDD refers Behavior Drive Development, that is, behavior-driven development. Here B is not referring to the Business, in fact, BDD can be seen as a supplement to the TDD, of course, you can also see it as a branch of TDD. Because in the TDD, we can not guarantee based on design written test is the user desired function. BDD this part is simple and naturalization, using natural language to describe, let the development, testing, BA and customers can reach agreement on this basis. Because the concept is not everyone can accept the test-first, some people may feel that the system is too complex and difficult to test, some people think that what does not exist can not be tested. So, here we are trying to convert an idea, and that is to consider its behavior, that is how it should be run, and can reach a consensus abstract norms.

TDD DEVELOPMENT STYLE

With all aspects of using test-driven development. By focusing on writing only need to pass the test code, it can be designed using other methods to realize more clearly than usual, more clearly. (Beck, 2003 )

Implement some advanced design concepts, such as design, test, design will be generated. The code may still simpler than the target schema, but still by all of the required tests. This may be unsettling for the first time, but it allows developers to focus on what is important

Writing tests first. The function of the test should be tested before being written to. It is claimed that has two benefits. It helps to ensure that the application of testability, because developers must consider how to test the application from the start, rather than worry about later. It also ensures that for each functional test will be written to. When writing a function of the first code, there is a tendency by the developers and development organisation developer on the next function, ignore the test completely.

Test-driven development of advanced practice, may lead to the acceptance test driven Development (ATTD), in which the conditions specified by the customer is automatic acceptance testing, and then drive the traditional Unit Test Driven Development (UTDD) course. This process ensures that the customer has an automated mechanism to determine whether the software meets the requirement of them. As the ATDD, development team now has a specific target, in order to satisfy, acceptance testing, which makes them constantly focus on the customer from the user’s real story.

TDD use Case

xUnit

Developers can use computer aided testing framework, developers can use the xUnit framework provides assertions, type test and the ability to report the results. Because they get rid of the post-processing of independent activities are included in the burden of a test to perform these functions to perform validation is the key to automation. The execution of the test framework provides a framework allowing all system test cases automatically or subset, along with other functions. (Meszaros, 2016)

pyUnit

PyUnit is an easy way to create unit testing programs and UnitTests with Python.

Here is an example

PYUnit

Test-driven development (TDD) before adding a new code to make your test code wrong kind of development technologies. TDD soon Agile developers use to application source code development, will soon be agile DBA for database development. TDD can be used as complementary methods (AMDD) agile model-driven development and both can be used together. TDD can not replace the traditional test, on the contrary it is to define a way to ensure the effectiveness of the verification unit testing. Another effect of TDD is to test the code as a code example, it can provide coding standard for us. In my experience, TDD in the actual development of the excellent performance of hard to believe that many agile developers consider it.

 

Reference

Ambysoft. (2003). Introduction to Test Driven Development (TDD). Retrieved from Agile Data: http://agiledata.org/essays/tdd.html

Beck, K. (2003 ). “Test-Driven Development by Example”,. Addison Wesley.

Boehm, B. W. (1981). “Software Engineering Economics”. Prentice-Hall: Englewood Cliffs.

75. Williams, E. M. (October, 1996 11). “Test-Driven Development. Proceedings of International Symposium on Software Reliability Engineering, pp. 66-75.

Meszaros, G. (2016, August 31). xUnit. Retrieved from Wikipedia: https://en.wikipedia.org/wiki/XUnit

Saiedian, D. S. (2008, March/April ). Does Test-Driven Development Really Improve Software Design Quality? I E E E S o f t w a r E, p. 77~83.