12
Pragmatic approach to TDD 13/11/2010, Agile Saturday, Tallinn

Pragmatic approach to TDD

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Pragmatic approach to TDD

Pragmatic approach to TDD

13/11/2010, Agile Saturday, Tallinn

Page 2: Pragmatic approach to TDD

Look, who’s talking!? Name: Dmitry Lebedev Experience: since 1997, developer, tester,

team-lead, architect, dev-manager Current company: Idea Port Riga Current hobby: non-profitable org DevExperts,

whish is responsible for Agile Latvia and JUG Latvia

Page 3: Pragmatic approach to TDD

What is TDD

Page 4: Pragmatic approach to TDD

So what?! Force to write tests Simplify your code Code becomes less coupled Tests become your safety net for changes

Page 5: Pragmatic approach to TDD

Ways to failure with TDD Advanced algorithms implementation

math multithreading

A lot of integrations May lead to tests overload with mocking Not everything could be mocked (java.net.URL) Might be hard to imitate real 3rd party components

Keep your coding habits Fear of writing tests Long methods Avoidance of refactoring

Page 6: Pragmatic approach to TDD

Ways to succeed with TDD Start from the scratch Setup your infrastructure first

Build scripts Continuous integration Version control

Define coding conventions Choose a platform which have built-in:

Architectural patterns Test support

Revise your coding habits

Page 7: Pragmatic approach to TDD

Design?! What is design?

a specification of an object, manifested by an agent, intended to accomplish goals, in a particular environment, using a set of primitive components, satisfying a set of requirements, subject to constraints;

Purpose of design Specify how goals could be accomplished Make fundamental statements on which to base

decisions Describe how separate pieces could be assembled

into whole

Page 8: Pragmatic approach to TDD

CRC Cards

Class : Web Browser

Responsibility: display

toolbars and page content

Collaboration: Toolbar, Web

Page

Page 9: Pragmatic approach to TDD

Agile Model Driven Development Iteration 0

Initial Requirements Envisioning Initial Architectural Envisioning

Iteration 1..n Iteration Modeling Model Storming Test Driven Development

http://www.agilemodeling.com/essays/amdd.htm

Page 10: Pragmatic approach to TDD

How to adopt TDD for ongoing projects Worst case

Creepy Design No Unit Tests

Better case Design is clear Some UT are present

Threats New code made by TDD may break old design Writing tests which affect already existing code

might be tricky You may need not only re-factor, but re-design

Page 11: Pragmatic approach to TDD

My experience with TDD and legacy project Make a prototype in code State results (CRC cards, Whiteboard, Free

form text) Erase prototype Start doing TDD

Page 12: Pragmatic approach to TDD

Questions?!