Test Driven iOS Development (TDD)
Post on 26-Jan-2015
119 Views
Preview:
DESCRIPTION
Transcript
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
top related