Test Driven iOS Development (TDD)

Preview:

DESCRIPTION

 

Citation preview

Test Driven iOS Development (TDD)p ( )

Md. Babul Mirdha,Senior Software Engineer, Mobile App Development,

Leads Corporation Limited

Contents

Programmer life without Automated Unit Testing.g g

Whst is xUnit?

What is TDD?

TDD is about Design, not Testing!

Demo

Programmer life without Automated Unit Testing

Programmer life without Unit Testing

Quickly write a lot of codeQ ysomeday ... something doesn’t work or stops working

Fixing a bug is easy...But finding the bug is a nightmare

Spend hours and days in front of the debugger

Fixing one could break other partsFixing one could break other parts

The bug could appear again later

Manual Testing

more expensive and time consumingp g

becomes boring

not reusable

provide limited Visibility and have to be repeated by all Stakeholders

Automated Testing

Reusable

Ensures repeatability (missing out)

Drives cleaner designg

Provide a Safety Net for Refactoring

Up-to-date specification documentp p f

Need a safety guard : Poka-Yoke

Poka-yoke is a Japanese term that means "mistake-proofing“, purpose is to eliminate product defects by preventing, correcting. The concept was formalised, and the term adopted, by Shigeo Shingo, who considered himself as the world’s leading expert on manufacturing practices and the Toyota Production System

What is xUnit?

xUuitBy keeping automated testing code, programmers can verify that they haven't broken something along the way.

xUnit is a Poka Yoke for software developmentxUnit is a Poka-Yoke for software development.

xUnit Tools

Many xUnit frameworks exist for various yprogramming languages and development platforms.

- .Net >> Nunit

i- Java >> Junit

- PHP>> Simple Test/ PHPUnit

- C++ >> gUnitC++ >> gUnit

- Python >> PyUnit

- Ruby >> Test::Unit

Objective-C >>OCUnit (SenTestingKit.Frameork)

What is TDD?

An iterative & incremental technique to develop software.

One must first write a test that fails before writing a new functional code.

A practice for efficiently developing useful code

Principle of TDD

Kent Beck defines:Never write a single line of code unless you have a failing automated test.

Eliminate duplication.

TDD = TFA+ Refactoring.

Red/Green/Refactor

Red (Automated test fail)( )

Green (Automated test pass because dev code has been written)

Refactor (Eliminate duplication, Clean the code)

Red

Refactor

Greed

What is Refactoring?

A series of Disciplined small steps, each of which changes the A series of Disciplined small steps, each of which changes the

program’s internal structure without changing its

external behavior, in order to improve some of the external behavior, in order to improve some of the nonfunctional attributes of the software .

Wh d f t i tWhen need refactoring to:Eliminate duplication

Requirement changes

Apply new design patternApply new design pattern

Rename class, object, variable & method names

Performance Optimization

Migrate to new technology.g gy

TDD in practice

Any program feature

without an automated test

i l d ’ i simply doesn’t exist - Kent Beck - Kent Beck

Principle of TDD (In Practice)

Start

TDD Rhythm: Test-> Code-> Refactor

Red

Write a Test

h

TDD Rhythm: Test-> Code-> Refactor

Green

Run the Test

See it fail, because there’s no dev code

RefactorMake a little change

(Dev Code) to compile

fail

Run the Test

pass

Refactoring

p

How to Write a Test

The AAA or 3A Pattern for Unit Tests –3Arrange: Set up data for the test.

Act: Perform the action of the test.

A V if h l f h Assert: Verify the result of the test.

How to Write a Test

Here is a simple unit test that follows the AAA ppattern:

-(void) testMax() {

// Arrange

int x = 1;

int y = 2;

// Act

int result = [Math maxBetween: x And: y )];

// Assert

STAssertEquals( result,y );

}}

Test is NOT a Unit Test

if it _has External Dependencies

can't run at the same time as any of other unit tests

h O d D d i O l k h i i has Order Dependencies - Only works when run in certain order

h b d di.e. Each Test must be independent.

TDD is about Design, not Testing!

Produces the simplest thing that works (but not the dumbest!)

Keeps it Simple And Short

Drives the design of the software through tests

Focuses on writing simple solutions for today’s requirementsg p y q

Writes just enough code to make the tests pass, and no more

Executable Test codes become requirement

TDD makes clean code that works

How does TDD achieve this?Predictable – Tells you when you are done or not

Learn – Teaches me all lessons that the code has to teach

Confidence – Green bar gives you more confidenceConfidence Green bar gives you more confidence

Documentation – Good starting point to understand code

Protection – Puts a test- harness (yoke) around your code

Advantages

Tests _Keep me out of the (time hungry) debugger!

Make Faster Development by eliminating Waste

R d B i N F d i E i i FReduce Bugs in New Features and in Existing Features

Reduce Cost of Change

If break some part, Red Bar appearIf break some part, Red Bar appear

Allow Refactoring, improve Design

Build a safety net and defend Against Other PProgrammers

Force me to Slow Down and Think

Executable documentationExecutable documentation

Test-Drive ASP.NET MVC by Jonathan McCracken

Research undertaken by Microsoft in conjunction with IBM

Research undertaken by Microsoft in conjunction with (h // h i f /IBM (http://research.microsoft.com/en-

us/groups/ese/nagappan_tdd.pdf)Case studies were conducted with three development Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the preThe results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did t th TDD ti did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.p p g

Organization of Tests

CaluculatorSenTestingKit Framework

Framesork

ProjectSenTestingKit.Framework

Dev TargetTest Target

Development Code Test Code

Assertions

If an assertion fails, then an error is reported.

If a test contains multiple assertions, any that follow the one that failed will not be executed.

For this reason, it's usually best to try for one assertion per test.

Some Asset Functions

STAssertEquals(a1, a2, msg, ...) q ( , , g, )The arguments a1 and a2 are C datatypes (for example, primitive values or structs) of the same type with equal values.

STAssertEquals (a1, a2, accuracy, msg, ...) WithAccuracy The C scalar values a1 and a2 are of the same WithAccuracy The C scalar values a1 and a2 are of the same type and have the same value to within ±accuracy.

Quick Demo on TDD with Temperature Converter

Tools used for this demo:- IDE : xCode

- Language : Objective-C

U i T i T l S T i Ki F k- Unit Testing Tool: SenTestingKit.Framework

- Refactoring Tool: xCode Refactor

The RequirementqConverts the Temperature: Celsius to Fahrenheit.

We know that40ºC is the same as 40ºF–40ºC is the same as –40ºF

30ºC is the same as 86ºF

TestCase: –40ºC is the same as –40ºF

@implementation TemperatureConverterTests

-(void) testThatMinusFortyCelsiusIsMinusFortyFahrenheit {

//Arrangeint celciousValue=-40;int expectedFarenheitValue=-40; int expectedFarenheitValue 40;

TemperatureConverter *converter= [[TemperatureConverter alloc] init];

//Actint actualFarenheitValue =[converter getFahrenhitFromCelcious:celciousValue];

//AssertSTAssertEquals(actualFarenheitValue, expectedFarenheitValue,@"Did not match with Minus

Forty Celsius and Minus Forty Fahrenheit");

}}

-(void) testThat30CelsiusIs86Fahrenheit {

//Arrangeint celciousValue=30;int expectedFarenheitValue=86;

TemperatureConverter *converter= [[TemperatureConverter alloc] init];

//Actint actualFarenheitValue =[converter getFahrenhitFromCelcious:celciousValue];

//AssertSTAssertEquals(actualFarenheitValue expectedFarenheitValue @"Did not match STAssertEquals(actualFarenheitValue, expectedFarenheitValue,@ Did not match

with Minus Forty Celsius and Minus Forty Fahrenheit");

}

d@end

If it doesn’t have automated unit tests, is not done.

Then we will get …

References

Kent Beck: Test-Driven Development: By Example, Addison-Wesley 2002Wesley, 2002.Test-Driven iOS Development by Graham LeeTest Driven .NET Development with FitNesse, Gojko AdzicTest-Driven Development in Microsoft NET by James W Newkirk Test Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov

http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264http://blogs.agilefaqs.com/http://www objectwind com/present/FitNesse htmhttp://www.objectwind.com/present/FitNesse.htmhttp://www.xprogramming.com/software.htmhttp://testdrivendeveloper.com/http://fit.c2.com/h //fi / iki i l dhttp://fit.c2.com/wiki.cgi?JavaDownloadshttp://fit.c2.com/wiki.cgi?DotNetDownloadshttp://fitnesse.org/http://sourceforge.net/projects/fitnesse

Q & AQ & A

Th k T AllThanks To All

Recommended