Introduction to Test-Driven Development.ppt - Bitbucket

concepcionsockSoftware and s/w Development

Aug 15, 2012 (4 years and 8 months ago)

421 views

Test
-
Driven
Development

Christopher Bartling

Why are you here?


Why are you interested in test
-
driven
development?


What do you hope to get out of this
session?


Did this session meet your expectations
with regards to introducing you to the
concepts of test
-
driven development?

Why test
-
driven?


Cheap: Finding bugs in development


Expensive: Finding bugs in production


Bugs can result in lost revenue


Integration project between two
companies lost $100,000 due to a
misunderstood requirement

What is TDD?


Writing tests to guide development


TDD is a
design

tool


Tests drive the development of
production code


Tests explain the intent of your class

How do you do TDD?


Write a test for a class.


If the class or method under test does
not yet exist, create it


Execute the test
--
it should
fail


Write the code in the class under test to
make the test pass
--
the test should
pass


Repeat until the class implements the
responsibility it needs to

When am I done?


When your class supports the
responsibility that it needs to for your
application


Do you know what responsibility your
class must support?


Strive for classes supporting a single
responsibility


Smaller, focused classes are easier to
maintain and test

What about
collaborators?


My class depends on other classes. It
collaborates with other objects


Use
test doubles

to stub, fake, spy, or
mock collaborations


Look to mock object frameworks to help
you implement test doubles

Mock objects


State verification


Direct outputs


Indirect outputs


Behavior verification

Refactoring


Change code to make it more flexible to
future changes


Does
not

change behavior


Tests are necessary to ensure you have
not changed behavior


Do refactoring all the time


Watch your technical debt

Programming by
intention


IDEs automate a lot of common
developer actions


Learn to use the IDE and plugins


Learn the refactorings


Learn key mappings


Eclipse, IntelliJ IDEA, NetBeans


Visual Studio, ReSharper add
-
in





Design tips


Single responsibility
principle (SRP)


Strive to have each class do one and
only one thing


Only one reason to change the class


Keeps classes small and cohesive


Easier to test and maintain


Refactor classes to move responsibilities
to other classes which can then
collaborate

Dependency injection


Promote loose coupling of classes


Always refer to interface types


Classes should not know about
implementation types


Use an assembler to wire up the
dependencies between classes

Don’t repeat yourself


DRY


Look out for copy and paste reuse


Static analysis tools can be used to root
out this behavior

Favor interface
inheritance


Use interfaces, especially when it
involves collaborations


Reusable implementation can be
delegated to by interface implementers


Implementation inheritance is fragile and
restrictive

Favor delegation


Favor composition over inheritance


Implementation inheritance is brittle


Composition is flexible


Use delegation instead of
implementation inheritance to reuse
common implementations

Recommended
Reading

Recommended
Reading

Discussion


Contact information


Email:
chris.bartling@gmail.com


Blog:
http://bartling.blogspot.com


Twitter: @cbartling


LinkedIn:
http://www.linkedin.com/in/chrisbartling