Test-Driven Development in Android Writing tests without (that much) pain

Do you have unit tests on your project?

How do you know your project works?

What is a unit test? @Test public void testSqrtWith25 () { //PREPARE SomeObjectToTest object = new SomeObjectToTest() ; //PERFORM int result = object.sqrt( 25); //CHECK assertEquals(5, result); }

Software testing pyramid

Software testing ice cream cone

Unit tests benefits 1) The only documentation that is always up to date 2) Making refactoring really possible 3) Adding new features without risks 4) Continuous testing

Knowing it works before (manually) testing it

F.I.R.S.T 1) Fast 2) Independent 3) Repeatable 4) Self-Validating 5) Timely Three 1’s 1) ONE logical branch 2) ONE concept to test 3) ONE way to structure Your testing is a joke © James Thomas

Smells of bad tests in the morning 1) If 2) assertTrue(x == y); 3) Evergreen tests 4) Test avalanche twice a week 5) Discussing private matters with your test 6) Reflection 7) Testing toString() 8) It’s hard to name the test

If your code wasn’t designed to be testable - it is not 1) Non-injected dependencies 2) Android framework dependencies 3) Static methods and variables

Run it!

Ok, so what is TDD?

Three Rules of TDD 1) If there is no test - there is no code 2) You write as much of the test as required for it to fail 3) You write as much of the code as required for the test to pass

Step 1: If there is no test - there is no code @Test public void testSqrtWith25 () { //PREPARE SomeObjectToTest object = new SomeObjectToTest() ; //PERFORM int result = object.sqrt( 25); //CHECK } public class SomeObjectToTest {}

Step 2: make your test pass... @Test public void testSqrtWith25 () { //PREPARE SomeObjectToTest object = new SomeObjectToTest() ; //PERFORM int result = object.sqrt( 25); //CHECK } public class SomeObjectToTest { public int sqrt(int value) { return 0; } }

Step 3: ...and then make it fail again @Test public void testSqrtWith25 () { //PREPARE SomeObjectToTest object = new SomeObjectToTest() ; //PERFORM int result = object.sqrt( 25); //CHECK assertEquals(5, result); //assertTrue(5 == result); } public class SomeObjectToTest { public int sqrt(int value) { return 0; } }

Unit test in TDD is the first user of your new functionality

What TDD is not 1) It’s not a religion - you change the rules the way it fits you 2) It’s not a silver bullet - it’s not making your code perfect instantly 3) It’s not a universal solution - it might be not required

Deciding on TDD/TLD/FTT

Thanks!