@PreusslerBerlin History • Started with test first from XP in 1999 by Kent Beck • Famous as TDD since Kent Becks book in 2003 • Just a rediscovery: test first was normal in early days of programming
@PreusslerBerlin History • Started with test first from XP in 1999 by Kent Beck • Famous as TDD since Kent Becks book in 2003 • Just a rediscovery: test first was normal in early days of programming
@PreusslerBerlin History • Started with test first from XP in 1999 by Kent Beck • Famous as TDD since Kent Becks book in 2003 • Just a rediscovery: test first was normal in early days of programming
@PreusslerBerlin “If you’re doing test-driven development well, you’ll never write comments in your code because your tests are a form of documentation for how your program should work,” (Alex Clark, Codecademy)
@PreusslerBerlin …there is one other [discipline] that is, and that’s Accounting. The right mistake … that one-digit error can crash the company and send the offenders off to jail. How do accountants deal with that sensitivity? Well, they have disciplines.
@PreusslerBerlin …there is one other [discipline] that is, and that’s Accounting. The right mistake … that one-digit error can crash the company and send the offenders off to jail. How do accountants deal with that sensitivity? Well, they have disciplines.
@PreusslerBerlin …there is one other [discipline] that is, and that’s Accounting. The right mistake … that one-digit error can crash the company and send the offenders off to jail. How do accountants deal with that sensitivity? Well, they have disciplines.
@PreusslerBerlin Dual entry book keeping Everything is said twice. Every transaction is entered two times — once on the credit side and once on the debit side. Those two transactions follow separate mathematical pathways until they end up at this wonderful subtraction on the balance sheet that has to yield to zero.
@PreusslerBerlin Dual entry book keeping Everything is said twice. Every transaction is entered two times — once on the credit side and once on the debit side. Those two transactions follow separate mathematical pathways until they end up at this wonderful subtraction on the balance sheet that has to yield to zero.
@PreusslerBerlin Dual entry book keeping Everything is said twice. Every transaction is entered two times — once on the credit side and once on the debit side. Those two transactions follow separate mathematical pathways until they end up at this wonderful subtraction on the balance sheet that has to yield to zero.
@PreusslerBerlin Dual entry book keeping This is what test-driven development is: dual-entry bookkeeping. Everything is said twice — once on the test side and once on the production code side and everything runs in an execution that yields either a green bar or a red bar just like the zero on the balance sheet.
@PreusslerBerlin Dual entry book keeping This is what test-driven development is: dual-entry bookkeeping. Everything is said twice — once on the test side and once on the production code side and everything runs in an execution that yields either a green bar or a red bar just like the zero on the balance sheet.
@PreusslerBerlin Dual entry book keeping This is what test-driven development is: dual-entry bookkeeping. Everything is said twice — once on the test side and once on the production code side and everything runs in an execution that yields either a green bar or a red bar just like the zero on the balance sheet.
@PreusslerBerlin The 3 rules of TDD • You must write a failing test before you write any production code. • You must not write more of a test than is sufficient to fail, or fail to compile. • You must not write more production code than is sufficient to make the currently failing test pass. nano-cycle (seconds)
@PreusslerBerlin The 3 rules of TDD • You must write a failing test before you write any production code. • You must not write more of a test than is sufficient to fail, or fail to compile. • You must not write more production code than is sufficient to make the currently failing test pass. nano-cycle (seconds)
@PreusslerBerlin The 3 rules of TDD • You must write a failing test before you write any production code. • You must not write more of a test than is sufficient to fail, or fail to compile. • You must not write more production code than is sufficient to make the currently failing test pass. nano-cycle (seconds)
@PreusslerBerlin Red Green Refactor • Create a unit tests that fails • Write just enough production code to makes that test pass. • Clean up the mess you just made. micro-cycle (minutes)
@PreusslerBerlin Red Green Refactor • Create a unit tests that fails • Write just enough production code to makes that test pass. • Clean up the mess you just made. micro-cycle (minutes)
@PreusslerBerlin Red Green Refactor • Create a unit tests that fails • Write just enough production code to makes that test pass. • Clean up the mess you just made. micro-cycle (minutes)
@PreusslerBerlin Babysteps The philosophy is based on the idea that our limited minds are not capable of pursuing the two simultaneous goals of all software systems: 1. Correct behavior. 2. Correct structure.
@PreusslerBerlin My experience • Less coupled to implementation • Less mocking • Forces small changes • Interruptions from colleagues always possible • No need for a ”flow” • Less stress
@PreusslerBerlin Isn’t it slow? Without TDD, you spend a few weeks writing code which mostly works and spend the next year "testing" and fixing many (but not all) of the bugs With TDD, you spend a year writing code which actually works. Then you do final integration testing for a few weeks.
@PreusslerBerlin Isn’t it slow? • Single feature will take longer • Bugfixing phase is shorter • Debugging disappears • Ci finds bugs before tester does • Long term it’s much faster no more big rewrite
@PreusslerBerlin TDD and architecture • TDD does not replace Architecture and Design • Have a vision in your head • NO big up front design • Defer architecture decisions as long as possible
@PreusslerBerlin TDD and architecture • TDD does not replace Architecture and Design • Have a vision in your head • NO big up front design • Defer architecture decisions as long as possible
@PreusslerBerlin TDD and architecture • TDD does not replace Architecture and Design • Have a vision in your head • No big up front design • Defer architecture decisions as long as possible
@PreusslerBerlin TDD and architecture • TDD does not replace Architecture and Design • Have a vision in your head • NO big up front design • Defer architecture decisions as long as possible
@PreusslerBerlin Android SDK under test • Empty methods with default return values android { … testOptions { unitTests.returnDefaultValues = true } -> no code will run
@PreusslerBerlin Tired of issues like java.lang.NullPointerException at org.robolectric.manifest.MetaData. init(MetaData.java:55) at org.robolectric.manifest.AndroidMa nifest.initMetaData(AndroidManifes t.java:377).... ? Sleepy by Tomas; flickr.com/photos/tma/2438467223; CC 2.0 Don’t spent more time fixing your test setup than fixing your app Sleepy by Tomas; flickr.com/photos/tma/2438467223; CC 2.0 Still valid?
@PreusslerBerlin Prototypes, POC and MVPs • For prototypes: hacking together is fine But after: start from scratch and build it test driven • For MVP: an MVP is a minimum feature set but no excuse for bad quality
@PreusslerBerlin More resources • Test Driven Development by Example (Kent Beck) • https://cleancoders.com/videos • https://online-training.jbrains.ca/p/wbitdd-01 • http://news.codecademy.com/test-driven- development/
dpreussler
takahirom
punchdrunker
natsumican63
en2zo
maroon1st
mitchan
blackbracken
itohiro73
andpad
a4lg
yusukebe
tanakahisateru
afnizarnur
iamctodd
frogandcode
mraible
bluesmoon
soudai
addyosmani
trishagee
caitiem20
eitanlees
paigeccino
thekraken