@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 …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 “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 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 Isn’t it slow? Writing tests is slower than not writing tests. You’ll write at least as much test code as production code TDD adds 10% — 30% on initial costs = longer to complete their projects
@PreusslerBerlin Isn’t it slow? Writing tests is slower than not writing tests. You’ll write at least as much test code as production code TDD adds 10% — 30% on initial costs = longer to complete their projects
@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? • 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 Violations of DRY are typically referred to as WET solutions, which is commonly taken to stand for either "write everything twice" or "we enjoy typing” (http://en.wikipedia.org/wiki/Don't_repeat_yourself)
@PreusslerBerlin Android SDK under test • Empty methods with default return values android { … testOptions { unitTests.returnDefaultValues = true } -> no code will run
@PreusslerBerlin Live coding • Manifest via lint lintOptions { check 'Registered' warningsAsErrors true } * Has issues with Gradle Plugin 3.0 and Kotlin @PreusslerBerlin
@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
@PreusslerBerlin What’s wrong with Robolectric? • Developers used too much magic forgot what unit test should be • Your tests rely on correct 3rd party implementation • Tests itself becomes flaky • It’s slower than pure JUnit
@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
gaelvaroquaux
minorun365
takuyay0ne
sadonosake
bumptakayuki
mixi_engineers
pauli
n1ru4l
karawoo
kazumax55
weaverryan
yosuke_furukawa
mongodb
cromwellryan
keathley
jonrohan
chriscoyier
trishagee
soudai
lynnandtonic
lauravandoore
hursman
chrislema