1. Test Driven iOS Development (TDD)p ( )
Md. Babul Mirdha,
Senior Software Engineer, Mobile App Development,
Leads Corporation Limited

2. Contents
Programmer life without Automated Unit Testing.g g
Whst is xUnit?
What is TDD?
TDD is about Design, not Testing!
Demo

3. Programmer life without Automated Unit Testing

4. Programmer life without Unit Testing
Quickly write a lot of codeQ y
someday ... 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

5. Manual Testing
more expensive and time consumingp g
becomes boring
not reusable
provide limited Visibility and have to be repeated by
all Stakeholders

6. Automated Testing
Reusable
Ensures repeatability (missing out)
Drives cleaner designg
Provide a Safety Net for Refactoring
Up-to-date specification documentp p f

7. 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

8. What is xUnit?
xUuit
By 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.

9. xUnit Tools
Many xUnit frameworks exist for variousy
programming 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)

10. 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

11. 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.

12. 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

13. What is Refactoring?
A series of Disciplined small steps, each of which changes theA 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 theexternal 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

14. TDD in practice
Any program feature
without an automated test
i l d ’ isimply doesn’t exist
- Kent Beck- Kent Beck

15. 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
Refactor
Make a little change
(Dev Code) to compile
fail
Run the Test
pass
Refactoring
p

16. How to Write a Test
The AAA or 3A Pattern for Unit Tests –3
Arrange: Set up data for the test.
Act: Perform the action of the test.
A V if h l f hAssert: Verify the result of the test.

17. How to Write a Test
Here is a simple unit test that follows the AAAp
pattern:
-(void) testMax() {
// Arrange
int x = 1;
int y = 2;
// Act
int result = [Math maxBetween: x And: y )];
// Assert
STAssertEquals( result,y );
}}

18. 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 ihas Order Dependencies - Only works when run in certain
order
h b d di.e. Each Test must be independent.

19. 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

20. 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

21. 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

22. Test-Drive ASP.NET MVC
by Jonathan McCracken

23. 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 developmentCase 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 tidid not use the TDD practice.
Subjectively, the teams experienced a 15–35% increase in
initial development time after adopting TDD.p p g

24. Organization of Tests
Caluculator
SenTestingKit Framework
Framesork
Project
SenTestingKit.Framework
Dev Target
Test Target
Development
Code Test Code

26. 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.

27. 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 sameWithAccuracy The C scalar values a1 and a2 are of the same
type and have the same value to within ±accuracy.

28. 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

29. The Requirementq
Converts the Temperature: Celsius to
Fahrenheit.
We know that
40ºC is the same as 40ºF–40ºC is the same as –40ºF
30ºC is the same as 86ºF

30. TestCase: –40ºC is the same as –40ºF
@implementation TemperatureConverterTests
-(void) testThatMinusFortyCelsiusIsMinusFortyFahrenheit {
//Arrange
int celciousValue=-40;
int expectedFarenheitValue=-40;int expectedFarenheitValue 40;
TemperatureConverter *converter= [[TemperatureConverter alloc] init];
//Act
int actualFarenheitValue =[converter getFahrenhitFromCelcious:celciousValue];
//Assert
STAssertEquals(actualFarenheitValue, expectedFarenheitValue,@"Did not match with Minus
Forty Celsius and Minus Forty Fahrenheit");
}}

31. -(void) testThat30CelsiusIs86Fahrenheit {
//Arrange
int celciousValue=30;
int expectedFarenheitValue=86;
TemperatureConverter *converter= [[TemperatureConverter alloc] init];
//Act
int actualFarenheitValue =[converter getFahrenhitFromCelcious:celciousValue];
//Assert
STAssertEquals(actualFarenheitValue expectedFarenheitValue @"Did not matchSTAssertEquals(actualFarenheitValue, expectedFarenheitValue,@ Did not match
with Minus Forty Celsius and Minus Forty Fahrenheit");
}
d@end

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

33. Then we will get …

34. References
Kent Beck: Test-Driven Development: By Example, Addison-
Wesley 2002Wesley, 2002.
Test-Driven iOS Development by Graham Lee
Test Driven .NET Development with FitNesse, Gojko Adzic
Test-Driven Development in Microsoft NET by James W NewkirkTest Driven Development in Microsoft .NET by James W. Newkirk
and Alexei A. Vorontsov
http://www.slideshare.net/nashjain/acceptance-test-driven-development-350264
http://blogs.agilefaqs.com/
http://www objectwind com/present/FitNesse htmhttp://www.objectwind.com/present/FitNesse.htm
http://www.xprogramming.com/software.htm
http://testdrivendeveloper.com/
http://fit.c2.com/
h //fi / iki i l dhttp://fit.c2.com/wiki.cgi?JavaDownloads
http://fit.c2.com/wiki.cgi?DotNetDownloads
http://fitnesse.org/
http://sourceforge.net/projects/fitnesse

35. Q & AQ & A

36. Th k T AllThanks To All