The document discusses testing and some common objections to writing tests. It addresses concerns like tests taking too much time, specs changing too often, tests being difficult to understand, and whether there are too many tests or too much code. It provides examples of simple, readable tests and discusses test-driven development principles like writing just enough tests to feel confident in changes without going overboard.

1. TESTING
Tomek Polanski
tpolansk
WHY?
WHEN?
HOW?

2. “Too much time pressure with making
visible changes.
Customer doesn't appreciate tests enough.”

3. “To make iterations as fast as possible I
would not use tests for prototypes or early
MVPs.”

4. “Specs are too volatile, tests would just
need to be updated constantly.”

5. “Writing tests is hard, they might be
difficult to understand.”

6. “Nobody else in the project uses them.
They weren't done or were broken when I
got involved.”

7. Time and budget
“Too much time
pressure with making
visible changes”

8. Instant changes Return on investment
vs

9. Speed
“Not for prototypes
or early MVPs”

10. Time
Progress

11. Prototype

12. Minimum
Viable
Product
Lovable
by Henrik Kniberg

13. Constant ChangeThe
“Specs are too
volatile”

14. Programming is hard
https://deeguns.files.wordpress.com/2013/07/computerman.jpg

15. urbanattitude.fr/wp-content/uploads/2015/03/BER_08.jpg

16. Architecture
“Tests are hard and
difficult to understand”

17. Maintenance
“Missing/broken
tests”

18. What should unit tests
look like?

19. Fast

20. Reliable

21. Simple to understand
@Test
public void get_whenElementExists() {
List<String> list = Collections.singletonList(DEFAULT);
assertThat(get(list, 0)).isEqualTo(DEFAULT);
}
@Test
public void get_whenIndexTooBig_returnNull() {
List<String> list = Collections.singletonList(DEFAULT);
assertThat(get(list, 1)).isNull();
}
@Test
public void get_whenIndexTooSmall_returnNull() {
List<String> list = Collections.singletonList(DEFAULT);
assertThat(get(list, -1)).isNull();
}

22. Simple to understand?

23. Arrange Act Assert

24. Test setup
@Test
public void test() {
List<Language> list = Arrays.asList(GERMAN, ENGLISH);
Mockito.when(mDataModel.getSupportedLanguages())
.thenReturn(list);
Mockito.when(mDataModel.getGreetingByLanguageCode(LanguageCode.EN))
.thenReturn("Hi!");
// The rest of the test
}

25. Arrange builder
class ArrangeBuilder {
ArrangeBuilder withLanguages(Language... languages) {
Mockito.when(mDataModel.getSupportedLanguages())
.thenReturn(Arrays.asList(languages));
return this;
}
ArrangeBuilder withGreetings(LanguageCode code, String greeting) {
Mockito.when(mDataModel.getGreetingByLanguageCode(code))
.thenReturn(greeting);
return this;
}
}

26. @Test
public void test() {
List<Language> list = Arrays.asList(GERMAN, ENGLISH);
Mockito.when(mDataModel.getSupportedLanguages())
.thenReturn(list);
Mockito.when(mDataModel.getGreetingByLanguageCode(LanguageCode.EN))
.thenReturn("Hi!");
// The rest of the test
}
@Test
public void test() {
new ArrangeBuilder()
.withLanguages(GERMAN, ENGLISH)
.withGreetings(LanguageCode.EN, "Hi!");
// The rest of the test
}
Arrange builder

27. Simple to write

28. Is it all?

29. Do I have enough tests?

30. static boolean isEven(int number) {
return number % 2 == 0;
}
static boolean isEven(int number) {
return number % 2 == 0 ? true : false;
}
What’s the code coverage?
@Test
public void isTwoEven() {
assertThat(isEven(2))
.isTrue();
}
static boolean isEven(int number) {
if ( number % 2 == 0 ) {
return true;
} else {
return false;
}
}

31. What’s the code coverage?
Observable<Boolean> isEven(int number) {
return Observable.just(number)
.map(num -> num % 2 == 0);
}
@Test
public void isTwoEven() {
TestSubscriber<Boolean> ts = new TestSubscriber<>();
isEven(2).subscribe(ts);
ts.assertValue(true);
}
@Test
public void isTwoEven() {
TestSubscriber<Boolean> ts = new TestSubscriber<>();
isEven(2).subscribe(ts);
}

32. Do I have too many tests?

33. Do I have too much code?

34. public class Translation {
public final String mText;
public Translation(String text) {
mText = text;
}
public String text() {
return mText;
}
} @AutoValue
public abstract class Translation {
public abstract String text();
public static Translation create(String text) {
return new AutoValue_Translation(text);
}
}
. public class Translation {
private final String mText;
public Translation(String text) {
mText = text;
}
public String text() {
return mText;
}
@Override
public int hashCode() {
return mText != null ? mText.hashCode() : 0;
}
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Translation that = (Translation) o;
return mText != null
? mText.equals(that.mText)
: that.mText == null;
}
}
. @Test
public void valueEquality() {
String value = "text";
Translation first = Translation.create(value);
Translation second = Translation.create(value);
assertThat(first).isEqualTo(second);
}
@AutoValue
public abstract class Translation {
public abstract String text();
public static Translation create(String text) {
return new AutoValue_Translation(text);
}
@Override
public int hashCode() {
// ...
}
@Override
public boolean equals(Object o) {
// ...
}
}

35. What is this code here?
Observable<String> getCurrentLanguage() {
return getSystemLanguage()
.skip(1)
.first();
}
Observable<String> getCurrentLanguage() {
return getSystemLanguage()
// .skip(1)
.first();
}

36. Test Driven Development
Less Code Less Tests Peace of mind

37. Be playful Don’t be dogmatic
Find a test mentor

38. “99 little bugs in the code
99 little bugs in the code
Take one down, patch I around
117 little bugs in the code”

39. “Stop breaking things!”
Tracy Rolling

40. Thank you!
tpolansk