is3242 case presentation

IS3242 Case Presentation

“Does Test-Driven Development Really Improve Software Design Quality?”

– David S. Janzen, Hossein Saiedian

27 JAN 2013

Clement Low Kang Jie Min Ivan Chew

Loh Soon Bock Tan Tze Jun


Presentation Agenda

2

1. Introduction to Test-Driven Development (TDD)

2. Misconceptions About TDD

3. TDD’s Impact on Software Quality

4. Article – Purpose of the Study

5. Article – Configuring the Study

6. Article – Results from the Study

7. Conclusion & Key Takeaways

“Does Test-Driven Development Really Improve Software Design Quality?” 3

1. Introduction to Test-Driven Development (TDD)


Introduction to Test-Driven Development (TDD)

4

Conventional Development ApproachCODE first, TEST later.

Test-Driven Development ApproachTEST first, CODE later.



5

Test-Driven Development ApproachTEST first, CODE later.

1. Define a unit-test to “frame” the way a method should behave as per the requirements specification.

2. Write code that passes the unit-test.

3. Refactor code to make it efficient and concise.



6

Derive a test-case from the requirements specification.

1. “Password must contain numbers.”

2. “Password length must be >= 8.”

TDD Step 1



7

Implement the method to be tested by the test-case.

TDD Step 2



8

Verify code against test-case until it passes.

TDD Step 3



9

Refactor code to clean it up if necessary.

TDD Step 4


2. Misconceptions About TDD


Misconceptions About TDD

11

MISCONCEPTION #1“TDD is ALL about automated testing.”

The guiding principle of the Test-First (TDD) approach is to ensure design quality. The emphasis is NOT on automated testing.

Test-First Test-LastAutomation

Manual Testing

TF & TL both involve automated testing, but they finally converge at manual testing.

Exactly what kind of manual testing? (next slide)


Misconceptions About TDD

12

MISCONCEPTION #2“Write ALL tests first, then go on and code.”

The Test-First (TDD) approach of creating tests first is to allow the software design to evolve and improve over a number of iterations.

You have 100 developers. What is a surefire way to verify if they are implementing according to requirements?

After all coding is finalized, the following will occur:• System Testing• Usability Testing• Integration Testing• User Acceptance Testing (UAT)


3. TDD’s Impact on Software Quality

McCall’s Quality Factors

• Efficiency

• Correctness

• Testability

• Maintainability

• Reusability


TDD’s Impact on Software Quality

14

External Quality; not the focus of the article

Internal Quality• Abstraction• Test Coverage• Code Size• Complexity• Coupling• Cohesion


TDD’s Impact on Software Quality

15

Constant optimization of code over short iterations. Fixes bugs early, saves money.

By focusing on design quality, TDD induces inherently positive results in quality metrics.

TDD is chiefly concerned with ensuring design quality.

TDD guides development by framing the specification requirements in unit tests.


4. Article – Purpose of the Study


Article – Purpose of the Study

Past Studies Focused on External Quality• Fewer defects but lower productivity.

• Minimal external quality differences but improved productivity.

• No change in productivity but more frequent unplanned test

failure.

More managerial in nature with somewhat mixed results.


What about internal quality (design)?

Article – Purpose of the Study

Code Size Complexity

Coupling Cohesion


5. Article – Configuring the Study


Article – Configuring the Study

20


6. Article – Results from the Study


Article – Results from the Study

22

IMPACT ON CODE SIZETest Coverage Lines/Class Lines/Method

Methods/Class• Number of test codes• Completing TF projects first

could have an effect in writing more test codes in subsequent TL/Projects



23


Methods/Class• TF programmers tend to

write smaller classes across all groups



24



write smaller (or shorter) methods



25



write fewer methods per class



26

IMPACT ON CODE SIZESummary

Area Impact

Test Coverage TF-TL tends to increase for 2 groups

Lines/Class TF tends to write smaller classes

Lines/Method TF tends to write smaller methods

Method/Class TF tends to write fewer methods per class

Tendency towards smaller, simpler classes and methods that are better tested.



27

MetricsCyclomatic Complexity Nested block depth

Coupling Fan-out Cohesion

[If module= ‘IS3242’]

[If …][If …]

[If …]

[If …]

Cyclomatic complexity = 6



28


Coupling Fan-out Cohesionpublic void dropModules(List<Module> pModules) { if (pModules == null || pModules.isEmpty()) { return; } else { for (Module objModule : pModules) { for (ModuleClass objClass : objModule) { if (objClass.getTime() …) … } // end for each class } // end for each module } // end if}

Nesting depth = 3Nesting depth (loops) = 2Nesting depth (branches) = 2



29


Coupling Fan-out Cohesion

Fan-in = 3Fan-out = 2



30


Coupling Fan-out CohesionSalesPage

MktPage

AccPage

SalesMktAccBean

Lack of cohesion



31

IMPACT ON COMPLEXITY Cyclomatic Complexity/Method

Weighted-Methods Complexity Nested-Block Depth/Method

• Number of independent

paths through code per

method

• ICS and INT-TF difference

were statistically significant.



32


Weighted-Methods Complexity Nested-Block Depth/Method

• Sum of cyclomatic

complexities for all

methods in a class

• ICS and ITF-TL difference

were statistically

significant.



33


Weighted-methods Complexity Nested-Block Depth/Method

• Degree of nesting• 3 of the studies shown TL

have lower NBD, however the values are low and difference are small.



34

IMPACT ON COMPLEXITYSummary

Area Impact

Cyclomatic Complexity per method TF tends to write simpler methods

Weighted-methods complexity TF tends to write simpler classes

Nested-block Depth per method * No Major Differences

Programmers using TDD approach tends to write less complex classes and methods.



35

IMPACT ON COUPLING, COHESIONCoupling Fan-out/Class Lack of Cohesion



36




37




38

IMPACT ON COUPLING, COHESIONSummary

Area Impact

Coupling Higher ?

Fan-out/Class Higher ?

Cohesion ?

Abstraction ?

Results Inconclusive!


7. Conclusion & Key Takeaways


Conclusion & Key Takeaways

40

Re-cap on Test-Driven Development (TDD)

TDD is a design practice that involves several test-code-refactor iterations.

Iteration 1 Iteration 2 Iteration N



41

Positive Outcomes of TDD

Smaller units of code, plausibly more cohesive.

More highly-tested code.

Less complex, plausibly more abstract code.



42

Constraints & Limitations of TDD

DESIGNChanges in requirements, design require

rework for UNIT TESTS and CODE.

More overhead!



43


TDD does NOT substitute OTHER FORMS of testing that are carried out in the final phases of software development.

TDD precedes

Example



44


TDD is more suitable for fine-grained and independent methods due to its design-centric nature which forces tests to be defined explicitly.

1. TDD approach used to develop ‘login()’.

2. But what if ‘logFailedAttempt()’ breaks?

Under what condition might this constraint manifest? (next slide)



45


TDD may be disruptive if it is introduced during development as it may break existing design patterns and cause coding inconsistencies.

TDD

EXAMPLENon-modular software design.

TDD favors “self-contained” methods that have little to no dependencies.


Any questions?

Thank you for your time!

is3242 case presentation

Technology

software design quality

testdriven development

internal quality design

ensuring design quality

guides development

software qualityby

external quality fewer

article results