CSC/ECE 517 Fall 2013/ch1 1w31 vm

Test Driven Development (Under Construction)

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right. Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

Rules of Thumb

Don’t write a line of new code unless you first have a failing automated test

Eliminate duplication. These rules generate complex individual and group behavior. Some of the technical implications are:

Design with organization

TDD recommends that programmers should write their code such that it provides feedback between decisions. It should exhibit a control hierarchy which is easy to manage and understand.

Write your own tests

This states that developers should write their own tests, since it is not advisable to wait for someone else to write a test every time. In a software environment, developers usually used to rely on testers to find bugs. However, this design says otherwise. It implies that developers know their code inside out and hence should write their own test cases.

Rapid Response

Your development environment must provide rapid response to small changes. Business requirments are generally fickle and they can change at any point of time. Hence, it is receommended that developers write code such that it can adapt to changes made in future.

High Cohesion

In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is. The design must consist of many highly cohesive, loosely coupled components, just to make testing easy.

Steps performed in TDD

The following sequence is based on the book Test-Driven Development by Example.[1]

Quickly add a test

In test-driven development, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed "new" feature already exists or the test is defective.) To write a test, the developer must clearly understand the feature's specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.

Run all tests and see the new one fail

This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases.

Make a little change

The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it. At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage.

Run all tests and see them all succeed

If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle.

Refactor to remove duplication

Now the code should be cleaned up as necessary. Move code from where it was convenient for passing the test to where it logically belongs. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design[5][6] to guide you, as well as anything else you know about writing clean code. By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality. The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to removing any duplication between the test code and the production code—for example magic numbers or strings repeated in both to make the test pass in step 3.

Levels of Test Driven Development

There are two levels of TDD:

Acceptance TDD (ATDD)

With ATDD developers write a single acceptance test, or behavioral specification depending on preferred terminology, and then just enough production functionality/code to fulfill that test. The goal of ATDD is to specify detailed, executable requirements for the solution be on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).

Developer TDD

With developer TDD a single developer test is written, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test. The goal of developer TDD is to specify a detailed, executable design for the solution be on a JIT basis. Developer TDD is often simply called TDD.

See more at: http://www.agiledata.org/essays/tdd.html#sthash.11uJfvXR.dpuf

Characteristics of Good Tests

For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:

Run fast (they have short setups, run times, and break downs).

Run in isolation (you should be able to reorder them).

Use data that makes them easy to read and to understand.

Use real data (e.g. copies of production data) when they need to.

Represent one step towards your overall goal.