Reduce Development Cost with Test Driven Development

Test Driven Development

Reduce Development CostWith Test Driven Development

J. Hank Rainwater, CTO of CTE

Noel Kierans, CEO of CTE

Sam Murthy Bharath, CEO of NetServ

1


The State of Software Development Today

2


The Cost of Fixing Bugs Late in the Development Cycle

3


The Search for Better Methodologies

The Classic Challenge:

A Better Way: TDD

TDD = Test Driven Design: improvements at the smallest level of construction

TDD = Test Driven Development: improvements in the overall delivery process

4


TD ‘Design’ at the lowestlevel:

4. A single atomic feature5. Negative Test6. Code Construction7. Positive Test8. Refactoring

5


TD ‘Design’: team units

6

Test Driven DevelopmentBeck & Astels 2003

TDD is a powerful way to produce well designed code with fewer defects The best way to write a code is to shape it from the beginning with Tests Fewer defects, lesser debugging, more confidence, better design & higher

productivity

TDD Goal > think of the design before you develop leading to “clean code that works”

Step A : Test First Design (TFD)1) Create a Test Case and Create a code small enough code to fail the test2) Next you run the test to ensure it fails3) Update the functional code to make it pass the test case4) If it fails update/fix the code to pass the tests

Step B : Refactoring1) Refactor any duplication out of design turning TFD into TDD

TDD = TFD + Refactoring

7

TDD using Unit Test Framework NUnit for .NET

Units are a piece of “isolatable functional code” > a Class or Method

Unit Tests are “programs written to run in batches and test classes”

UTFs help developers test using their development language and IDE

Traditional UTFs used “Derived Classes” to develop test classes

NUnit uses a concept of “Attributes” which are highly scalable

NUnit uses a Test Runner application to do Unit Testing

Test Runner runs tests identifying the NUnit “attributes” in the code

NUnit provides the following attributes

a. Test Fixture Attribute indicates a class contains Test Methods

b. Test Attribute indicates a method is a test method to be run by TestRunner

c. Setup & Teardown helps create setups before and after each tests

d. Expected Exception helps create a try..catch statement to catch test exception

e. Ignore helps ignore a test temporarily if need arises

f. Assertion Class helps actually test what has happened is what you wanted to happen

9) NUnit has a GUI / Console app to run against Test Assemblies

10) Test Assembly is a class library that contains Test Fixtures

11) Test Fixtures contains Test Attributes

8

C# Example using NUnit Framework

Task: Create an unbounded Stack which include Push, Pop & IsEmpty operations

Create a Test List:• Create a Stack & verify that IsEmpty is true• Push a single object on the stack & verify that IsEmpty is true• Push a single object, Pop the object & verify that IsEmpty is true• Push a single object, remembering what it is; Pop the object & verify they are equal• Push three objects, remembering what it is; Pop each one, and verify they are removed in the

correct order• Pop a stack that has no elements• Push a single object and then Call Top. Verify that IsEmty is False• Call Top on a Stack with no elements

Run Tests:

Test 1: Create a Stack & verify that IsEmpty is true

9

Using System;Using Nunit.Framework;[TestFixture]Public class StackFixture{[Test]Public void Empty(){ Stack stack = new Stack() Asser.IsTrue(stack.isEmpty);}

Test fails to compileStack missing

public class Stack{ private bool isEmpty = true; public bool isEmpty { get { return isEmpty; } }

Code compilesRuns in NUnitGreen Bar Displays

C# Example using NUnit Framework (continued)

Test 2: Create a Stack & verify that IsEmpty is true

10

Using System;Using Nunit.Framework;[TestFixture]Public class StackFixture{[Test]Public void PushOne(){ Stack stack = new Stack(); stack.Push(“first element”); Assert.IsTrue(stack.IsEmpty, “After Push, IsEmpty should be false);}Public void Push(object element){}

Using System;Using Nunit.Framework;[TestFixture]Public class StackFixture{[Test]Public void PushOne(){ Stack stack = new Stack(); stack.Push(“first element”); Assert.IsTrue(stack.IsEmpty, “After Push, IsEmpty should be false);}Public void Push(object element){ isEmpty = false;}

Failure: StackFixture.PushOne: “After Push, IsEmpty should be false”

Everything OK

TDD: Case Study - NetServ

Netserv has successfully implemented the concept of SDUs with a few of our clients and currently have 1 to 6 SDUs working per client locations

The SDUs have Project/QA Lead at the client location

Regular SCRUM Sessions between SDUs and Project Leads

Creates a seamless pipeline from the SDUs to the Stakeholders

QA/Project lead with the SDU Testers execute any Blackbox/Regression/Integration Testing

Result

24 Hour throughput

Well documented and tracked process

Continuous Whitebox and Regression Testing

Well designed code with very fewer defects

Cost effective Development Solution

Good Balance between Onshore team , Offshore team and Stakeholders

11

Scaling TDD thru Agile Model Driven Development AMDD

TDD is good at detailed specification, Validation & design

TDD is not good thru bigger issues like overall design, UI design

AMDD addresses the scaling issues which TDD does not

12

Initial requirements Envisioning

Initial Architecture Envisioning

Iteration2:Development

Iteration 1:Development

Model Storming

Iteration Modeling

TDD

Iteration 0: Development

AMDD & TDD

The Other Dimension

TD ‘Development’:

3. Driven by testprogress metrics

2. Managed bydiscipline wheremetrics provideevidence foraction

Test progress is an aggregation of many factors

13

TDD: Case Study - CTE

• A Project In Trouble: three years into a two year project, the first version had yet to be delivered. Public promises had been made but a delivery date wasn’t in sight.

• Corporate Culture: the bureaucratic viscosity of the organization hampered agile processes.

• An Aggressive Timeline: key project milestones were sometimes established based on corporate needs and public promises rather than estimates derived from actual development progress.

14


15


16

CTE took these steps to improve the delivery process, using metric-based testing data as the evidence to drive change:

Realigned tasks and personnel to better fit skills and depth of experience.

Held daily team meetings with QA staff to coordinate testing efforts. Often these were of the ‘scrum’ variety and often held standing.

Mentored staff as needed to increase motivation and effectiveness.

Generated daily metrics and weekly reports for all teams that informed leadership decisions.

Reviewed test scripts and execution plans with QA and development staff at regular intervals.

Coordinated daily conference calls with off-shore developers and performed triage on project priorities.

Implemented best practices with test management tools.


17

Lessons Learned

Synchronize your project plan and test management tools.

Keep the progress data up-to-date

Take action when the data indicates problems

Finding the RIGHT Balance

18

Increased Costs

Longer Projects

Higher Risk

Lower ROI

Costs are LEAN

Shorter Projects

Reduce Risk

Optimize ROI


19

Employ management BASICS: Business Acumen: all team members must have an understanding of the business

processes that they are attempting to test. Knowledge of the context of the problems software is designed to solve is essential and will require mentoring and directed assignments.

Strategy: TDD offers a new strategy. The tactics that lead to the strategic benefits will be unique in your organization but embracing the vision of improvement will motivate team members and leaders alike to make the sometimes painful changes required.

Innovation: trying something new can be part of strategy but it must be justified by the standards and constraints of the corporate development ecosystem. With TDD you are using an innovative strategy but as you put it into practice, don’t be afraid to tweak it as needed as you learn what works best for your teams. Just don’t stray from the core principle of writing tests before writing code!

Common Sense: without being redundant, common sense often means using basic management practices such as never expecting what you don’t inspect and holding personnel accountable for their performance. The whole concept of a SDU practicing TDD is based on accountability in a small group – something much easier to manage than large and disconnected teams where finger pointing can take precedence over problem solving.


20

Implementing TDD in Your Organization

Changing Relationships in Your Team

Developers, testers and users have different perspectives

Be aware of typical misconceptions

TDD = >Agile => Lean => $avings at the bottom line


21

Thanks for your attention!

It’s time for your questions.

Technology

Reduce Development Cost with Test Driven Development