SlideShare a Scribd company logo
1 of 21
Download to read offline
TEST-DRIVEN DEVELOPMENT
1
Test-Driven Development (TDD)
• Test-driven development (TDD) is a software
development process that relies on the repetition of a very
short development cycle:
• first the developer writes an (initially failing) automated test case
that defines a desired improvement or new function,
• then produces the minimum amount of code to pass that test,
• and finally refactors the new code to acceptable standards.
• Kent Beck, who is credited with having developed or
'rediscovered' the technique, stated in 2003 that TDD
encourages simple designs and inspires confidence.
• Test-driven development is related to the test-first
programming concepts of extreme programming, begun in
1999.
2
TDD Cycle
1. Add a test
2. Run all tests to see if new one fails
3. Write some code
4. Run test
5. Refactor code
6. Repeat
3
1. Add a test
• In TDD, each new feature begins with writing a test. This
test must inevitably fail because it is written before the
feature has been implemented. To write a test, the
developer must clearly understand the feature's
specification and requirements.
• The developer can accomplish this through use cases
and user stories to cover the requirements and exception
conditions, and can write the test in whatever testing
framework is appropriate to the software environment.
This could also be a modification of an existing test.
• This is a differentiating feature of test-driven development
versus writing unit tests after the code is written: it makes
the developer focus on the requirements before writing
the code, a subtle but important difference.
4
2. Run all tests to see if new one fails
• This validates that the test harness is working correctly
and that the new test does not mistakenly pass without
requiring any new code.
• This step also tests the test itself, in the negative: it rules
out the possibility that the new test always passes, and
therefore is worthless. The new test should also fail for the
expected reason. This increases confidence (though does
not guarantee) that it is testing the right thing, and passes
only in intended cases.
5
3. Write some code
• The next step is to write some code that causes the test to
pass. The new code written at this stage is not perfect,
and may, for example, pass the test in an inelegant way.
That is acceptable because later steps improve and hone
it.
• At this point, the only purpose of the written code is to
pass the test; no further (and therefore untested)
functionality should be predicted and 'allowed for' at any
stage.
6
4. Run tests
• If all test cases now pass, the programmer can be
confident that the code meets all the tested requirements.
This is a good point from which to begin the final step of
the cycle.
7
5. Refactor code
• Now the code should be cleaned up as necessary.
Remove any duplication you can find. Make sure that
variable and method names represent their current use.
Clarify any constructs that might be misinterpreted. Use
Kent Beck's four rules of simple design to guide you, as
well as anything else you know about writing clean code.
• By re-running the test cases, the developer can be
confident that code refactoring is not damaging any
existing functionality.
• The concept of removing duplication is an important
aspect of any software design.
8
6. Repeat
• Starting with another new test, the cycle is then repeated
to push forward the functionality.
• The size of the steps should always be small. If new code
does not rapidly satisfy a new test, or other tests fail
unexpectedly, the programmer should undo or revert in
preference to excessive debugging.
9
Development style
• There are various aspects to using test-driven
development, for example the principles of "keep it simple
stupid" (KISS) and "You aren't gonna need it" (YAGNI). By
focusing on writing only the code necessary to pass tests,
designs can often be cleaner and clearer than is achieved
by other methods.
• To achieve some advanced design concept, such as a
design pattern, tests are written that generate that design.
The code may remain simpler than the target pattern, but
still pass all required tests. This can be unsettling at first
but it allows the developer to focus only on what is
important.
10
Development style
• Write the tests first. The tests should be written before the
functionality that is being tested. This has been claimed to have
many benefits. It helps ensure that the application is written for
testability, as the developers must consider how to test the
application from the outset, rather than worrying about it later. It
also ensures that tests for every feature get written.
• Additionally, writing the tests first drives a deeper and earlier
understanding of the product requirements, ensures the
effectiveness of the test code, and maintains a continual focus
on the quality of the product. When writing feature-first code,
there is a tendency by developers and the development
organisations to push the developer on to the next feature,
neglecting testing entirely. The first test might not even compile,
at first, because all of the classes and methods it requires may
not yet exist. Nevertheless, that first test functions as an
executable specification.
11
Benefits
• A 2005 study found that using TDD meant writing more tests and, in
turn, programmers who wrote more tests tended to be more
productive. Hypotheses relating to code quality and a more direct
correlation between TDD and productivity were inconclusive.
• Programmers using pure TDD on new ("greenfield") projects reported
they only rarely felt the need to invoke a debugger. Used in
conjunction with a version control system, when tests fail
unexpectedly, reverting the code to the last version that passed all
tests may often be more productive than debugging.
• Test-driven development offers more than just simple validation of
correctness, but can also drive the design of a program. By focusing
on the test cases first, one must imagine how the functionality is used
by clients. So, the programmer is concerned with the interface before
the implementation. This benefit is complementary to Design by
Contract as it approaches code through test cases rather than
through mathematical assertions or preconceptions.
12
Benefits
• Test-driven development offers the ability to take small steps when
required. It allows a programmer to focus on the task at hand as the
first goal is to make the test pass. Exceptional cases and error
handling are not considered initially, and tests to create these
extraneous circumstances are implemented separately. Test-driven
development ensures in this way that all written code is covered by at
least one test. This gives the programming team, and subsequent
users, a greater level of confidence in the code.
• While it is true that more code is required with TDD than without TDD
because of the unit test code, the total code implementation time
could be shorter. Large numbers of tests help to limit the number of
defects in the code. The early and frequent nature of the testing helps
to catch defects early in the development cycle, preventing them from
becoming endemic and expensive problems. Eliminating defects early
in the process usually avoids lengthy and tedious debugging later in
the project.
13
Benefits
• TDD can lead to more modularized, flexible, and extensible
code. This effect often comes about because the methodology
requires that the developers think of the software in terms of
small units that can be written and tested independently and
integrated together later. This leads to smaller, more cohesive
classes, looser coupling, and cleaner interfaces.
• Because no more code is written than necessary to pass a
failing test case, automated tests tend to cover every code
path. For example, for a TDD developer to add an else branch
to an existing if statement, the developer would first have to
write a failing test case that motivates the branch. As a result,
the automated tests resulting from TDD tend to be very
thorough: they detect any unexpected changes in the code's
behaviour. This detects problems that can arise where a
change later in the development cycle unexpectedly alters
other functionality.
14
Shortcomings
• Test-driven development reliance on unit tests does not
perform sufficient testing in situations where full functional tests
are required to determine success or failure.
• Examples of these are user interfaces, programs that work with
databases, and some that depend on specific network
configurations. TDD encourages developers to put the
minimum amount of code into such modules and to maximize
the logic that is in testable library code, using fakes and mocks
to represent the outside world.
• Management support is essential. Without the entire
organization believing that test-driven development is going to
improve the product, management may feel that time spent
writing tests is wasted.
15
Shortcomings
• Unit tests created in a test-driven development
environment are typically created by the developer who is
writing the code being tested. The tests may therefore
share the same blind spots with the code:
• If, for example, a developer does not realize that certain input
parameters must be checked, most likely neither the test nor the
code will verify these input parameters.
• If the developer misinterprets the requirements specification for the
module being developed, both the tests and the code will be wrong,
as giving a false sense of correctness.
• The high number of passing unit tests may bring a false
sense of security, resulting in fewer additional software
testing activities, such as integration testing and
compliance testing.
16
Shortcomings
• Tests become part of the maintenance overhead of a project.
Badly written tests are themselves prone to failure, are
expensive to maintain. There is a risk that tests that regularly
generate false failures will be ignored, so that when a real
failure occurs, it may not be detected. It is possible to write
tests for low and easy maintenance, and this should be a goal
during the code refactoring phase described above.
• Overtesting can consume time both to write the excessive
tests, and later, to rewrite the tests when requirements change.
Also, more-flexible modules (with limited tests) might accept
new requirements without the need for changing the tests. For
those reasons, testing for only extreme conditions, or a small
sample of data, can be easier to adjust than a set of highly
detailed tests.
17
Shortcomings
• The level of coverage and testing detail achieved during
repeated TDD cycles cannot easily be re-created at a
later date. Therefore these original, or early, tests become
increasingly precious as time goes by. The tactic is to fix it
early. Also, if a poor architecture, a poor design, or a poor
testing strategy leads to a late change that makes dozens
of existing tests fail, then it is important that they are
individually fixed. Merely deleting, disabling or rashly
altering them can lead to undetectable holes in the test
coverage.
18
Designing for testability
• Complex systems require an architecture that meets a range of
requirements. A key subset of these requirements includes
support for the complete and effective testing of the system.
Effective modular design yields components that share traits
essential for effective TDD.
• High Cohesion ensures each unit provides a set of related capabilities
and makes the tests of those capabilities easier to maintain.
• Low Coupling allows each unit to be effectively tested in isolation.
• Published Interfaces restrict Component access and serve as contact
points for tests, facilitating test creation and ensuring the highest
fidelity between test and production unit configuration.
19
Designing for testability
• A key technique for building effective modular architecture
is Scenario Modeling where a set of sequence charts is
constructed, each one focusing on a single system-level
execution scenario.
• The Scenario Model provides an excellent vehicle for
creating the strategy of interactions between components
in response to a specific stimulus.
• Each of these Scenario Models serves as a rich set of
requirements for the services or functions that a
component must provide, and it also dictates the order
that these components and services interact together.
Scenario modeling can greatly facilitate the construction
of TDD tests for a complex system
20
Managing tests for large systems
• In a larger system the impact of poor component quality is
magnified by the complexity of interactions.
• This magnification makes the benefits of TDD accrue even
faster in the context of larger projects. However, the complexity
of the total population of tests can become a problem in itself,
eroding potential gains. It sounds simple, but a key initial step
is to recognise that test code is also important software and
should be produced and maintained with the same rigor as the
production code.
• Creating and managing the architecture of test software within
a complex system is just as important as the core product
architecture.
21

More Related Content

What's hot

Software testing and quality assurance
Software testing and quality assuranceSoftware testing and quality assurance
Software testing and quality assuranceBenjamin Baumann
 
Agile Software Development with XP
Agile Software Development with XPAgile Software Development with XP
Agile Software Development with XPVashira Ravipanich
 
Introduction To Extreme Programming
Introduction To Extreme ProgrammingIntroduction To Extreme Programming
Introduction To Extreme ProgrammingJoe Drumgoole
 
A Not-So-Serious Introduction to Test Driven Development (TDD)
A Not-So-Serious Introduction to Test Driven Development (TDD) A Not-So-Serious Introduction to Test Driven Development (TDD)
A Not-So-Serious Introduction to Test Driven Development (TDD) CodeOps Technologies LLP
 
Unit 1 basic concepts of testing & quality
Unit 1   basic concepts of testing & qualityUnit 1   basic concepts of testing & quality
Unit 1 basic concepts of testing & qualityravikhimani1984
 
Test Driven Development (TDD)
Test Driven Development (TDD)Test Driven Development (TDD)
Test Driven Development (TDD)David Ehringer
 
John Fodeh Adventures in Test Automation - EuroSTAR 2013
John Fodeh Adventures in Test Automation - EuroSTAR 2013John Fodeh Adventures in Test Automation - EuroSTAR 2013
John Fodeh Adventures in Test Automation - EuroSTAR 2013TEST Huddle
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Developmentguestc8093a6
 
Types of Software Testing: Definition, Objectives and Advantages
Types of Software Testing: Definition, Objectives and AdvantagesTypes of Software Testing: Definition, Objectives and Advantages
Types of Software Testing: Definition, Objectives and AdvantagesSimform
 

What's hot (15)

Software testing and quality assurance
Software testing and quality assuranceSoftware testing and quality assurance
Software testing and quality assurance
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Agile Software Development with XP
Agile Software Development with XPAgile Software Development with XP
Agile Software Development with XP
 
Introduction To Extreme Programming
Introduction To Extreme ProgrammingIntroduction To Extreme Programming
Introduction To Extreme Programming
 
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd   seven years afterIan Cooper webinar for DDD Iran: Kent beck style tdd   seven years after
Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after
 
A Not-So-Serious Introduction to Test Driven Development (TDD)
A Not-So-Serious Introduction to Test Driven Development (TDD) A Not-So-Serious Introduction to Test Driven Development (TDD)
A Not-So-Serious Introduction to Test Driven Development (TDD)
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Manual Testing.
Manual Testing.Manual Testing.
Manual Testing.
 
Unit 1 basic concepts of testing & quality
Unit 1   basic concepts of testing & qualityUnit 1   basic concepts of testing & quality
Unit 1 basic concepts of testing & quality
 
Test Driven Development (TDD)
Test Driven Development (TDD)Test Driven Development (TDD)
Test Driven Development (TDD)
 
John Fodeh Adventures in Test Automation - EuroSTAR 2013
John Fodeh Adventures in Test Automation - EuroSTAR 2013John Fodeh Adventures in Test Automation - EuroSTAR 2013
John Fodeh Adventures in Test Automation - EuroSTAR 2013
 
TestDrivenDeveloment
TestDrivenDevelomentTestDrivenDeveloment
TestDrivenDeveloment
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Software Testing or Quality Assurance
Software Testing or Quality AssuranceSoftware Testing or Quality Assurance
Software Testing or Quality Assurance
 
Types of Software Testing: Definition, Objectives and Advantages
Types of Software Testing: Definition, Objectives and AdvantagesTypes of Software Testing: Definition, Objectives and Advantages
Types of Software Testing: Definition, Objectives and Advantages
 

Viewers also liked (20)

32º domingo toc 2013 bene pagola
32º domingo toc 2013 bene pagola32º domingo toc 2013 bene pagola
32º domingo toc 2013 bene pagola
 
Avatar...
Avatar...Avatar...
Avatar...
 
20160428褒揚景文科技大學董事長故張文雄先生案
20160428褒揚景文科技大學董事長故張文雄先生案20160428褒揚景文科技大學董事長故張文雄先生案
20160428褒揚景文科技大學董事長故張文雄先生案
 
Bilbranchen i USA april 2016
Bilbranchen i USA april 2016Bilbranchen i USA april 2016
Bilbranchen i USA april 2016
 
Icebergs Estriados Da Antartida
Icebergs Estriados Da AntartidaIcebergs Estriados Da Antartida
Icebergs Estriados Da Antartida
 
4º pascua b 2012
4º pascua  b   20124º pascua  b   2012
4º pascua b 2012
 
Lneadetiempo 110804152533-phpapp01
Lneadetiempo 110804152533-phpapp01Lneadetiempo 110804152533-phpapp01
Lneadetiempo 110804152533-phpapp01
 
Array in C++
Array in C++Array in C++
Array in C++
 
Acta pastoral 06 febrero 2012 - Jerez
Acta pastoral 06 febrero 2012 - JerezActa pastoral 06 febrero 2012 - Jerez
Acta pastoral 06 febrero 2012 - Jerez
 
Acta pastoral 26nvbre2011
Acta pastoral 26nvbre2011Acta pastoral 26nvbre2011
Acta pastoral 26nvbre2011
 
Can gúia
Can gúiaCan gúia
Can gúia
 
As flores falan
As flores falanAs flores falan
As flores falan
 
Mysqlpresentation
MysqlpresentationMysqlpresentation
Mysqlpresentation
 
Planeaciones mes de Mayo
Planeaciones mes de MayoPlaneaciones mes de Mayo
Planeaciones mes de Mayo
 
Domingo 30º t.o.
Domingo 30º t.o.Domingo 30º t.o.
Domingo 30º t.o.
 
De Sara
De SaraDe Sara
De Sara
 
Entendendo o Diabetes
Entendendo o DiabetesEntendendo o Diabetes
Entendendo o Diabetes
 
Inumano
InumanoInumano
Inumano
 
1ª sessão do Processo de RVCC
1ª sessão do Processo de RVCC1ª sessão do Processo de RVCC
1ª sessão do Processo de RVCC
 
O defecto da muller
O defecto da mullerO defecto da muller
O defecto da muller
 

Similar to Test driven development

TDD and Unit Testing in Golang
TDD and Unit Testing in GolangTDD and Unit Testing in Golang
TDD and Unit Testing in GolangSofian Hadiwijaya
 
Test-Driven Development Reference Card
Test-Driven Development Reference CardTest-Driven Development Reference Card
Test-Driven Development Reference CardSeapine Software
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Developmentbhochhi
 
Test-Driven Development
Test-Driven DevelopmentTest-Driven Development
Test-Driven DevelopmentMeilan Ou
 
Week 14 Unit Testing.pptx
Week 14  Unit Testing.pptxWeek 14  Unit Testing.pptx
Week 14 Unit Testing.pptxmianshafa
 
Topic production code
Topic production codeTopic production code
Topic production codeKavi Kumar
 
Software Development Standard Operating Procedure
Software Development Standard Operating Procedure Software Development Standard Operating Procedure
Software Development Standard Operating Procedure rupeshchanchal
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Developmentnikhil sreeni
 
The Essentials Of Test Driven Development
The Essentials Of Test Driven Development The Essentials Of Test Driven Development
The Essentials Of Test Driven Development Rock Interview
 
Test-Driven-Development.pptx
Test-Driven-Development.pptxTest-Driven-Development.pptx
Test-Driven-Development.pptxdheeraj438799
 
{10.0} Test Driven Development.pptx
{10.0} Test Driven Development.pptx{10.0} Test Driven Development.pptx
{10.0} Test Driven Development.pptxAmalEldhose2
 
Testing, a pragmatic approach
Testing, a pragmatic approachTesting, a pragmatic approach
Testing, a pragmatic approachEnrico Da Ros
 
Android tdd
Android tddAndroid tdd
Android tddNhan Cao
 
Test Driven Development - Overview and Adoption
Test Driven Development - Overview and AdoptionTest Driven Development - Overview and Adoption
Test Driven Development - Overview and AdoptionPyxis Technologies
 

Similar to Test driven development (20)

TDD and Unit Testing in Golang
TDD and Unit Testing in GolangTDD and Unit Testing in Golang
TDD and Unit Testing in Golang
 
Tdd
TddTdd
Tdd
 
Test-Driven Development Reference Card
Test-Driven Development Reference CardTest-Driven Development Reference Card
Test-Driven Development Reference Card
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Lecture 21
Lecture 21Lecture 21
Lecture 21
 
Agile Testing - What is it?
Agile Testing - What is it?Agile Testing - What is it?
Agile Testing - What is it?
 
Agile Testing
Agile Testing  Agile Testing
Agile Testing
 
Test-Driven Development
Test-Driven DevelopmentTest-Driven Development
Test-Driven Development
 
Test driven development(tdd)
Test driven development(tdd)Test driven development(tdd)
Test driven development(tdd)
 
Week 14 Unit Testing.pptx
Week 14  Unit Testing.pptxWeek 14  Unit Testing.pptx
Week 14 Unit Testing.pptx
 
Topic production code
Topic production codeTopic production code
Topic production code
 
Software Development Standard Operating Procedure
Software Development Standard Operating Procedure Software Development Standard Operating Procedure
Software Development Standard Operating Procedure
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
The Essentials Of Test Driven Development
The Essentials Of Test Driven Development The Essentials Of Test Driven Development
The Essentials Of Test Driven Development
 
Test-Driven-Development.pptx
Test-Driven-Development.pptxTest-Driven-Development.pptx
Test-Driven-Development.pptx
 
{10.0} Test Driven Development.pptx
{10.0} Test Driven Development.pptx{10.0} Test Driven Development.pptx
{10.0} Test Driven Development.pptx
 
Methodology: IT test
Methodology: IT testMethodology: IT test
Methodology: IT test
 
Testing, a pragmatic approach
Testing, a pragmatic approachTesting, a pragmatic approach
Testing, a pragmatic approach
 
Android tdd
Android tddAndroid tdd
Android tdd
 
Test Driven Development - Overview and Adoption
Test Driven Development - Overview and AdoptionTest Driven Development - Overview and Adoption
Test Driven Development - Overview and Adoption
 

More from James Wong

Multi threaded rtos
Multi threaded rtosMulti threaded rtos
Multi threaded rtosJames Wong
 
Business analytics and data mining
Business analytics and data miningBusiness analytics and data mining
Business analytics and data miningJames Wong
 
Data mining and knowledge discovery
Data mining and knowledge discoveryData mining and knowledge discovery
Data mining and knowledge discoveryJames Wong
 
Big picture of data mining
Big picture of data miningBig picture of data mining
Big picture of data miningJames Wong
 
How analysis services caching works
How analysis services caching worksHow analysis services caching works
How analysis services caching worksJames Wong
 
Optimizing shared caches in chip multiprocessors
Optimizing shared caches in chip multiprocessorsOptimizing shared caches in chip multiprocessors
Optimizing shared caches in chip multiprocessorsJames Wong
 
Directory based cache coherence
Directory based cache coherenceDirectory based cache coherence
Directory based cache coherenceJames Wong
 
Abstract data types
Abstract data typesAbstract data types
Abstract data typesJames Wong
 
Abstraction file
Abstraction fileAbstraction file
Abstraction fileJames Wong
 
Hardware managed cache
Hardware managed cacheHardware managed cache
Hardware managed cacheJames Wong
 
Abstract class
Abstract classAbstract class
Abstract classJames Wong
 
Object oriented analysis
Object oriented analysisObject oriented analysis
Object oriented analysisJames Wong
 
Concurrency with java
Concurrency with javaConcurrency with java
Concurrency with javaJames Wong
 
Data structures and algorithms
Data structures and algorithmsData structures and algorithms
Data structures and algorithmsJames Wong
 
Cobol, lisp, and python
Cobol, lisp, and pythonCobol, lisp, and python
Cobol, lisp, and pythonJames Wong
 

More from James Wong (20)

Data race
Data raceData race
Data race
 
Multi threaded rtos
Multi threaded rtosMulti threaded rtos
Multi threaded rtos
 
Recursion
RecursionRecursion
Recursion
 
Business analytics and data mining
Business analytics and data miningBusiness analytics and data mining
Business analytics and data mining
 
Data mining and knowledge discovery
Data mining and knowledge discoveryData mining and knowledge discovery
Data mining and knowledge discovery
 
Cache recap
Cache recapCache recap
Cache recap
 
Big picture of data mining
Big picture of data miningBig picture of data mining
Big picture of data mining
 
How analysis services caching works
How analysis services caching worksHow analysis services caching works
How analysis services caching works
 
Optimizing shared caches in chip multiprocessors
Optimizing shared caches in chip multiprocessorsOptimizing shared caches in chip multiprocessors
Optimizing shared caches in chip multiprocessors
 
Directory based cache coherence
Directory based cache coherenceDirectory based cache coherence
Directory based cache coherence
 
Abstract data types
Abstract data typesAbstract data types
Abstract data types
 
Abstraction file
Abstraction fileAbstraction file
Abstraction file
 
Hardware managed cache
Hardware managed cacheHardware managed cache
Hardware managed cache
 
Object model
Object modelObject model
Object model
 
Abstract class
Abstract classAbstract class
Abstract class
 
Object oriented analysis
Object oriented analysisObject oriented analysis
Object oriented analysis
 
Concurrency with java
Concurrency with javaConcurrency with java
Concurrency with java
 
Data structures and algorithms
Data structures and algorithmsData structures and algorithms
Data structures and algorithms
 
Cobol, lisp, and python
Cobol, lisp, and pythonCobol, lisp, and python
Cobol, lisp, and python
 
Inheritance
InheritanceInheritance
Inheritance
 

Recently uploaded

9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxUdaiappa Ramachandran
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 

Recently uploaded (20)

9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
Building AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptxBuilding AI-Driven Apps Using Semantic Kernel.pptx
Building AI-Driven Apps Using Semantic Kernel.pptx
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 

Test driven development

  • 2. Test-Driven Development (TDD) • Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: • first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, • then produces the minimum amount of code to pass that test, • and finally refactors the new code to acceptable standards. • Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. • Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999. 2
  • 3. TDD Cycle 1. Add a test 2. Run all tests to see if new one fails 3. Write some code 4. Run test 5. Refactor code 6. Repeat 3
  • 4. 1. Add a test • In TDD, each new feature begins with writing a test. This test must inevitably fail because it is written before the feature has been implemented. To write a test, the developer must clearly understand the feature's specification and requirements. • The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. This could also be a modification of an existing test. • This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference. 4
  • 5. 2. Run all tests to see if new one fails • This validates that the test harness is working correctly and that the new test does not mistakenly pass without requiring any new code. • This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This increases confidence (though does not guarantee) that it is testing the right thing, and passes only in intended cases. 5
  • 6. 3. Write some code • The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect, and may, for example, pass the test in an inelegant way. That is acceptable because later steps improve and hone it. • At this point, the only purpose of the written code is to pass the test; no further (and therefore untested) functionality should be predicted and 'allowed for' at any stage. 6
  • 7. 4. Run tests • If all test cases now pass, the programmer can be confident that the code meets all the tested requirements. This is a good point from which to begin the final step of the cycle. 7
  • 8. 5. Refactor code • Now the code should be cleaned up as necessary. Remove any duplication you can find. Make sure that variable and method names represent their current use. Clarify any constructs that might be misinterpreted. Use Kent Beck's four rules of simple design to guide you, as well as anything else you know about writing clean code. • By re-running the test cases, the developer can be confident that code refactoring is not damaging any existing functionality. • The concept of removing duplication is an important aspect of any software design. 8
  • 9. 6. Repeat • Starting with another new test, the cycle is then repeated to push forward the functionality. • The size of the steps should always be small. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. 9
  • 10. Development style • There are various aspects to using test-driven development, for example the principles of "keep it simple stupid" (KISS) and "You aren't gonna need it" (YAGNI). By focusing on writing only the code necessary to pass tests, designs can often be cleaner and clearer than is achieved by other methods. • To achieve some advanced design concept, such as a design pattern, tests are written that generate that design. The code may remain simpler than the target pattern, but still pass all required tests. This can be unsettling at first but it allows the developer to focus only on what is important. 10
  • 11. Development style • Write the tests first. The tests should be written before the functionality that is being tested. This has been claimed to have many benefits. It helps ensure that the application is written for testability, as the developers must consider how to test the application from the outset, rather than worrying about it later. It also ensures that tests for every feature get written. • Additionally, writing the tests first drives a deeper and earlier understanding of the product requirements, ensures the effectiveness of the test code, and maintains a continual focus on the quality of the product. When writing feature-first code, there is a tendency by developers and the development organisations to push the developer on to the next feature, neglecting testing entirely. The first test might not even compile, at first, because all of the classes and methods it requires may not yet exist. Nevertheless, that first test functions as an executable specification. 11
  • 12. Benefits • A 2005 study found that using TDD meant writing more tests and, in turn, programmers who wrote more tests tended to be more productive. Hypotheses relating to code quality and a more direct correlation between TDD and productivity were inconclusive. • Programmers using pure TDD on new ("greenfield") projects reported they only rarely felt the need to invoke a debugger. Used in conjunction with a version control system, when tests fail unexpectedly, reverting the code to the last version that passed all tests may often be more productive than debugging. • Test-driven development offers more than just simple validation of correctness, but can also drive the design of a program. By focusing on the test cases first, one must imagine how the functionality is used by clients. So, the programmer is concerned with the interface before the implementation. This benefit is complementary to Design by Contract as it approaches code through test cases rather than through mathematical assertions or preconceptions. 12
  • 13. Benefits • Test-driven development offers the ability to take small steps when required. It allows a programmer to focus on the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are not considered initially, and tests to create these extraneous circumstances are implemented separately. Test-driven development ensures in this way that all written code is covered by at least one test. This gives the programming team, and subsequent users, a greater level of confidence in the code. • While it is true that more code is required with TDD than without TDD because of the unit test code, the total code implementation time could be shorter. Large numbers of tests help to limit the number of defects in the code. The early and frequent nature of the testing helps to catch defects early in the development cycle, preventing them from becoming endemic and expensive problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project. 13
  • 14. Benefits • TDD can lead to more modularized, flexible, and extensible code. This effect often comes about because the methodology requires that the developers think of the software in terms of small units that can be written and tested independently and integrated together later. This leads to smaller, more cohesive classes, looser coupling, and cleaner interfaces. • Because no more code is written than necessary to pass a failing test case, automated tests tend to cover every code path. For example, for a TDD developer to add an else branch to an existing if statement, the developer would first have to write a failing test case that motivates the branch. As a result, the automated tests resulting from TDD tend to be very thorough: they detect any unexpected changes in the code's behaviour. This detects problems that can arise where a change later in the development cycle unexpectedly alters other functionality. 14
  • 15. Shortcomings • Test-driven development reliance on unit tests does not perform sufficient testing in situations where full functional tests are required to determine success or failure. • Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations. TDD encourages developers to put the minimum amount of code into such modules and to maximize the logic that is in testable library code, using fakes and mocks to represent the outside world. • Management support is essential. Without the entire organization believing that test-driven development is going to improve the product, management may feel that time spent writing tests is wasted. 15
  • 16. Shortcomings • Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. The tests may therefore share the same blind spots with the code: • If, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify these input parameters. • If the developer misinterprets the requirements specification for the module being developed, both the tests and the code will be wrong, as giving a false sense of correctness. • The high number of passing unit tests may bring a false sense of security, resulting in fewer additional software testing activities, such as integration testing and compliance testing. 16
  • 17. Shortcomings • Tests become part of the maintenance overhead of a project. Badly written tests are themselves prone to failure, are expensive to maintain. There is a risk that tests that regularly generate false failures will be ignored, so that when a real failure occurs, it may not be detected. It is possible to write tests for low and easy maintenance, and this should be a goal during the code refactoring phase described above. • Overtesting can consume time both to write the excessive tests, and later, to rewrite the tests when requirements change. Also, more-flexible modules (with limited tests) might accept new requirements without the need for changing the tests. For those reasons, testing for only extreme conditions, or a small sample of data, can be easier to adjust than a set of highly detailed tests. 17
  • 18. Shortcomings • The level of coverage and testing detail achieved during repeated TDD cycles cannot easily be re-created at a later date. Therefore these original, or early, tests become increasingly precious as time goes by. The tactic is to fix it early. Also, if a poor architecture, a poor design, or a poor testing strategy leads to a late change that makes dozens of existing tests fail, then it is important that they are individually fixed. Merely deleting, disabling or rashly altering them can lead to undetectable holes in the test coverage. 18
  • 19. Designing for testability • Complex systems require an architecture that meets a range of requirements. A key subset of these requirements includes support for the complete and effective testing of the system. Effective modular design yields components that share traits essential for effective TDD. • High Cohesion ensures each unit provides a set of related capabilities and makes the tests of those capabilities easier to maintain. • Low Coupling allows each unit to be effectively tested in isolation. • Published Interfaces restrict Component access and serve as contact points for tests, facilitating test creation and ensuring the highest fidelity between test and production unit configuration. 19
  • 20. Designing for testability • A key technique for building effective modular architecture is Scenario Modeling where a set of sequence charts is constructed, each one focusing on a single system-level execution scenario. • The Scenario Model provides an excellent vehicle for creating the strategy of interactions between components in response to a specific stimulus. • Each of these Scenario Models serves as a rich set of requirements for the services or functions that a component must provide, and it also dictates the order that these components and services interact together. Scenario modeling can greatly facilitate the construction of TDD tests for a complex system 20
  • 21. Managing tests for large systems • In a larger system the impact of poor component quality is magnified by the complexity of interactions. • This magnification makes the benefits of TDD accrue even faster in the context of larger projects. However, the complexity of the total population of tests can become a problem in itself, eroding potential gains. It sounds simple, but a key initial step is to recognise that test code is also important software and should be produced and maintained with the same rigor as the production code. • Creating and managing the architecture of test software within a complex system is just as important as the core product architecture. 21