Test Driven Development – (TDD)

21
Test-Driven Development – (TDD) Author: Priyank Gairola

description

Test Driven Development

Transcript of Test Driven Development – (TDD)

Page 1: Test Driven Development – (TDD)

Test-Driven Development – (TDD)Author: Priyank Gairola

Page 2: Test Driven Development – (TDD)

Test Driven Development 2

TDD – A SnippetTest-driven development is an evolutionary

approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.

Some say it’s a programming technique.Precisely it is a technique whereby you

write your test cases before you write any implementation code.

Tests drive or dictate the code that is developed.

“TDD is risk averse programming, investing work in the near term to avoid failures later on”

Page 3: Test Driven Development – (TDD)

Test Driven Development 3

TDD – Goals…? It gives you a chance to learn the lessons the code

has to teach you. If you only hack together the first thing you can think of, you won't have the chance to think of a second, better thing.

It improves the lives of the users of your software. Keep in mind that if you don't test your software, your users will..

It is a predictable way to develop. You know when you are finished without worries about a long bug trail.

It lets your teammates count on you, and you on them.

It just feels good to see the green bar (i.e. all tests passing).

Page 4: Test Driven Development – (TDD)

Test Driven Development 4

Stages in TDD…? Write a single test Compile it. It shouldn’t compile because

you’ve not written the implementation code

Implement just enough code to get the test to compile

Run the test and see it fail Implement just enough code to get the

test to pass Run the test and see it pass Re-factor for clarity and “once and only

once” Repeat

Page 5: Test Driven Development – (TDD)

Test Driven Development 5

Write a test

Compile

Fix compile errors

Run test,watch it fail

Write code

Run test, watch it pass

Refactor code(and test)

Stages in TDD…?

Page 6: Test Driven Development – (TDD)

Test Driven Development 6

TDD Life CycleWrite Test

Compile

Run & See the

Fail

Refactor As

Needed

Page 7: Test Driven Development – (TDD)

Test Driven Development 7

ExampleWe want to develop a method that, given two Integers, returns an Integer that is the sum of parameters.

Page 8: Test Driven Development – (TDD)

Test Driven Development 8

• TestInteger i = new

Integer(5);Integer j = new

Integer(2);Object o = sum(i, j);

• Method

Example (cont.)

Page 9: Test Driven Development – (TDD)

Test Driven Development 9

• TestInteger i = new

Integer(5);Integer j = new

Integer(2);Object o = sum(i,

j);

• Methodpublic Object sum(Integer

i, Integer j) {return new Object();

}

Example (cont.)

Page 10: Test Driven Development – (TDD)

Test Driven Development 10

• TestInteger i = new

Integer(5);Integer j = new

Integer(2);Object o = sum(i,

j);if (o instanceof

Integer) return true;

elsereturn false;

• Methodpublic Object

sum(Integer i, Integer j) {return new Object();

}

Example (cont.)

Page 11: Test Driven Development – (TDD)

Test Driven Development 11

• TestInteger i = new

Integer(5);Integer j = new

Integer(2);Object o = sum(i, j);if (o instanceof

Integer) return true;

elsereturn false;

• Methodpublic Integer

sum(Integer i, Integer j) {return new Integer();

}

Example (cont.)

Page 12: Test Driven Development – (TDD)

Test Driven Development 12

• TestInteger i = new

Integer(5);Integer j = new

Integer(2);Object o = sum(i,

j);if ((o instanceof

Integer) && ((new Integer(7)) .equals(o))return true;

elsereturn false;

• Methodpublic Integer

sum(Integer i, Integer j) {return new Integer();

}

Example (cont.)

Page 13: Test Driven Development – (TDD)

Test Driven Development 13

• TestInteger i = new

Integer(5);Integer j = new

Integer(2);Object o = sum(i, j);if ((o instanceof

Integer) && ((new Integer(7)).equals(o))return true;

elsereturn false;

• Methodpublic Integer

sum(Integer i, Integer j) {return new Integer (i.intValue() + j.intValue());

}

Example (cont.)

Page 14: Test Driven Development – (TDD)

Test Driven Development 14

Traditional Vs. Test Driven Approach…?

Page 15: Test Driven Development – (TDD)

Test Driven Development 15

S. No

Traditional Approach Test Driven Approach

1 Pick a feature or a user requirement

Pick a feature or a user requirement

2 Write the production code that implements the feature

or user requirement.

Write a test that fulfills a small task or piece of the

feature or user requirement (e.g. one

method) and have the test fail.

3 Write the tests to validate the feature or user

requirement.

Write the production code that implements the task

and will pass the test.

4 Run all the tests. Run all of the tests.

5 Refactor if necessary Refactor the production and test code to make

them as simple as possible, ensuring all tests

pass.

6 Repeat steps 2 to 5 until the feature or user

requirement is implemented.

Traditional Vs. Test Driven Approach…?

Page 16: Test Driven Development – (TDD)

Test Driven Development 16

Benefits of TDD…?Test Driven Development contributes to software development practice from many aspects such as requirements definition, writing clean and well designed code, and change and configuration management. Few other benefits can be summarized as:Simpler Development Process -: Developers who use TDD are more focused. The only thing that a TDD developer has to worry about is getting the next test to pass. The goal is focusing the attention on a small piece of the software, getting it to work, and moving on rather than trying to create the software by doing a lot of up-front design.Improved Communication -: Communicating how a piece of software will work is not always easy with words or pictures. Words are often imprecise when it comes to explaining the complexities of the functionality of software. The unit tests can serve as a common language that can be used to communicate the exact behaviour of a software component without ambiguities.

Page 17: Test Driven Development – (TDD)

Test Driven Development 17

Improved Understanding of Required Software Behaviour -: The level of requirements on a project varies greatly. Sometimes requirements are very detailed and other times they are vague. Writing unit tests before writing the code helps developers focus on understanding the required behaviour of the software. Each of these pass/fail criteria adds to the knowledge of how the software must behave. As more unit tests are added because of new features or new bugs, the set of unit tests come to represent a set of required behaviours of higher and higher fidelity.Reduced Design Complexity -: Developers try to be forward looking and build flexibility into software so that it can adapt to the ever-changing requirements and requests for new features. Developers are always adding methods into classes just in case they may be needed. This flexibility comes at the price of complexity. In the TDD process, developers will constantly be refactoring code. Having the confidence to make major code changes any time during the development cycle will prevent developers from overbuilding the software and allow them to keep the design simple

Benefits of TDD…?

Page 18: Test Driven Development – (TDD)

Test Driven Development 18

Advantages of TDD…? TDD shortens the programming

feedback loop TDD promotes the development of high-

quality code User requirements more easily

understood Reduced interface misunderstandings TDD provides concrete evidence that

your software works Reduced software defect rates Better Code Less Debug Time

Page 19: Test Driven Development – (TDD)

Test Driven Development 19

Programmers like to code, not to test Test writing is time consuming Test completeness is difficult to judge TDD may not always work

Disadvantages of TDD…?

Page 20: Test Driven Development – (TDD)

Test Driven Development 20

TDD is a design technique that needs a little bit of extra time for planning ahead. It doesn’t necessarily improve the client’s experience. If they are more interested in development time rather than the quality of code, then they might not appreciate TDD designed code itself. TDD relies on the inherent human nature to fix things. Writing tests are important but not essential. We might forget them. TDD will actually show a ‘broken’ status if any test fails, this is a great incentive to fix tests. People tend to make a lot of design decisions while writing test cases. This is a good side effect of TDD. Lot of corner case which are missed while coding get importance upfront and by the time you are coding you are aware of them, rather than other way around. This is why the design is better for TDD.

Conclusion

Page 21: Test Driven Development – (TDD)

Test Driven Development 21