Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Writing Tests that Stand the Test of Time - dro...

Writing Tests that Stand the Test of Time - droidcon Boston

This talk was given at droidcon Boston 2019 (https://www.droidcon-boston.com/) in Boston, MA, United States.

Video: Not available yet.

Description:

One of the promises of test-driven development is the confidence and ease with which we can refactor our production code.

However, sometimes we find ourselves in situations where our tests are too coupled to our code and we have to change the tests every time we update the code. At this point, we start wondering if the tests are worth it.

If you have ever found yourself having to update your tests every time the behavior of a dependency of a class changes, then this talk is for you.

This talk is to share some patterns, tools, and examples that can guide us to write more maintainable tests.

We will look at why we need tests in the first place, how writing tests is an investment that will save time in the future. We will also look at some causes of unmaintainable tests (for example using a wrong test double, testing implementation details and not general behavior) and how to overcome these problems. With the use of examples from everyday Android development, we will learn how to avoid brittle tests.

You will leave the talk having a clearer understanding of why tests are important and worth the time and ultimately be able to apply the tips to write robust and more maintainable tests.

Segun Famisa

April 08, 2019
Tweet

More Decks by Segun Famisa

Other Decks in Programming

Transcript

  1. Outline Introduction to TDD Challenges with TDD Testing tools in

    practice Writing maintainable tests Recap
  2. TDD is a software development process that relies on the

    repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only Wikipedia “
  3. TDD is a software development process that relies on the

    repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only Wikipedia
  4. TDD is a software development process that relies on the

    repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only Wikipedia
  5. Why do we need tests? • Quick feedback about bugs/errors

    • Good code design • Documentation for code behavior
  6. Why do we need tests? • Quick feedback about bugs/errors

    • Good code design • Documentation for code behavior • Confident refactoring
  7. Challenges in practicing TDD Bad tests • Fragile and obscure

    tests defeat the purpose of TDD • “Bad tests” is worse than no tests - time and effort wasted without results
  8. Test doubles - stubs • Objects that return predefined data

    • They usually don’t hold state/respond to other actions besides the one they are created for
  9. Test doubles - stubs interface IUserRepository {...} ... class UserRepository(private

    val userDao: UserDao) : IUserRepository { override fun getUser(userId: Long): User { return userDao.findById(userId = userId) } }
  10. Test doubles - stubs interface IUserRepository {...} ... class UserRepository(private

    val userDao: UserDao) : IUserRepository { override fun getUser(userId: Long): User { return userDao.findById(userId = userId) } }
  11. Test doubles - stubs interface IUserRepository {...} ... class UserRepositoryStub()

    : IUserRepository { override fun getUser(userId: Long): User { return User(userId = 1, email = "[email protected]") } } Stub returns a preconfigured user
  12. Test doubles - fakes • Similar to stubs, slightly more

    realistic • Contain working implementation, but different from real version • Typically models the behavior of the real class
  13. Test doubles - fakes interface UserDao {...} ... class FakeUserDao()

    : UserDao { val users = mutableListOf<User>() override fun insert(user: User) { users.add(user) } override fun findById(userId: Long): User { return users.find { it.userId == userId } ?: throw Exception("user not found") } }
  14. Test doubles - fakes interface UserDao {...} ... class FakeUserDao()

    : UserDao { val users = mutableListOf<User>() override fun insert(user: User) { users.add(user) } override fun findById(userId: Long): User { return users.find { it.userId == userId } ?: throw Exception("user not found") } } Fake dao uses a list instead of a db
  15. Test doubles - fakes interface UserDao {...} ... class FakeUserDao()

    : UserDao { val users = mutableListOf<User>() override fun insert(user: User) { users.add(user) } override fun findById(userId: Long): User { return users.find { it.userId == userId } ?: throw Exception("user not found") } } Fake dao supports the same operations
  16. Test doubles - mocks • Objects pre-programmed with expected outputs

    for given inputs • Ability to record method calls and verify them • Throw exceptions if wanted method is not called
  17. Test doubles - mocks @Test fun userShouldBeReturnedFromDao() { val dao:

    UserDao = mock() whenever(dao.getUser(userId = 5)).thenReturn(User(5, "[email protected]")) ... }
  18. Test doubles - mocks @Test fun userShouldBeReturnedFromDao() { val dao:

    UserDao = mock() whenever(dao.getUser(userId = 5)).thenReturn(User(5, "[email protected]")) ... } Mock pre-programmed with input/output
  19. Test doubles - mocks // SettingsPresenterTest.kt @Test fun clickingIconShouldOpenProfileScreen() {

    ... val view: SettingsContract.View = mock() val presenter = SettingsPresenter(view, userRepo) presenter.profileIconClicked() verify(view).openProfileScreen() }
  20. Test doubles - mocks Ability to verify interactions // SettingsPresenterTest.kt

    @Test fun clickingIconShouldOpenProfileScreen() { ... val view: SettingsContract.View = mock() val presenter = SettingsPresenter(view, userRepo) presenter.profileIconClicked() verify(view).openProfileScreen() }
  21. Test doubles - spies • Hybrid between stubs, fakes and

    mocks • They are as real as stubs, but also have the ability to record interactions like mocks.
  22. What are maintainable tests? Tests are maintainable when: • Old

    tests do not break often • Old tests are easy to update
  23. What are maintainable tests? Tests are maintainable when: • Old

    tests do not break often • Old tests are easy to update • Easy to add new tests
  24. 1. Use a good test specification system Also known as

    Arrange - Act - Assert Or Given - When - Then Set up dependencies Exercise Verify
  25. 1. Use a good test specification system @Test fun scenarioX()

    { // Given the dependencies/behavior // When we act on the scenario // Then assert that expected behavior happens }
  26. 2. Test behavior, not implementation details • For methods that

    return value, you should care only about the output, not how it was calculated.
  27. 2. Test behavior, not implementation details @Test fun `get user

    details from cache if available`() { ... val userRepo = UserRepository(cacheSource, networkSource) // given that a user exists in cache whenever(cacheSource.getUser(5)).thenReturn(User(5, "[email protected]")) // when we get user from repository val user = userRepo.getUser(userId = 5) // then verify that the cache source was called verify(cacheSource).getUser(5) }
  28. 2. Test behavior, not implementation details @Test fun `get user

    details from cache if available`() { ... val userRepo = UserRepository(cacheSource, networkSource) // given that a user exists in cache whenever(cacheSource.getUser(5)).thenReturn(User(5, "[email protected]")) // when we get user from repository val user = userRepo.getUser(userId = 5) // then verify that the cache source was called verify(cacheSource).getUser(5) } This tests implementation details
  29. 2. Test behavior, not implementation details @Test fun `get user

    details from cache if available`() { ... // given that a user exists in cache val cachedUser = User(5, "[email protected]") whenever(cacheSource.getUser(5)).thenReturn(cachedUser) // when we get user from repository val returnedUser = userRepo.getUser(userId = 5) // then verify that the returned user is the one from cache assertEquals(cachedUser, returnedUser) }
  30. 2. Test behavior, not implementation details @Test fun `get user

    details from cache if available`() { ... // given that a user exists in cache val cachedUser = User(5, "[email protected]") whenever(cacheSource.getUser(5)).thenReturn(cachedUser) // when we get user from repository val returnedUser = userRepo.getUser(userId = 5) // then verify that the returned user is the one from cache assertEquals(cachedUser, returnedUser) } This tests general behavior of this repository in this scenario.
  31. 2. Test behavior, not implementation details • For methods that

    return value, one should care only about the output, not how it was calculated. • For methods that do not return any value, verify interactions with dependencies
  32. 2. Test behavior, not implementation details • For methods that

    return value, one should care only about the output, not how it was calculated. • For methods that do not return any value, verify interactions with dependencies • Be careful about overusing mocks.
  33. 3. Assert/verify only one thing per test In most cases,

    only one assert / verify should be done in each test.
  34. 3. Assert/verify only one thing per test In most cases,

    only one assert / verify should be done in each test. A test should fail for only 1 reason
  35. 3. Assert/verify only one thing per test @Test fun `enabling

    setting updates preference and sends tracking`() { ... // when user enables the setting viewModel.enableSetting() // then verify that we set preference verify(userPreference).enableSetting() // then verify that we send tracking verify(trackingUtils).trackUserEnabledSetting() }
  36. 3. Assert/verify only one thing per test @Test fun `enabling

    setting updates preference and sends tracking`() { ... // when user enables the setting viewModel.enableSetting() // then verify that we set preference verify(userPreference).enableSetting() // then verify that we send tracking verify(trackingUtils).trackUserEnabledSetting() }
  37. 3. Assert/verify only one thing per test @Test fun `enabling

    setting updates preference and sends tracking`() { ... // when user enables the setting viewModel.enableSetting() // then verify that we set preference verify(userPreference).enableSetting() // then verify that we send tracking verify(trackingUtils).trackUserEnabledSetting() } The use of “and” suggests that the test is testing more than one thing
  38. 3. Assert/verify only one thing per test @Test fun `enabling

    setting updates preference`() { ... // then verify that we set preference verify(userPreference).enableSetting() } @Test fun `enabling setting posts tracking`() { ... // then verify that we post tracking verify(trackingUtils).trackUserEnabledSetting() }
  39. 4. Use descriptive test names From the test name, we

    should be able to tell why the test failed.
  40. 4. Use descriptive test names From the test name, we

    should be able to tell why the test failed. @Test fun `search field is updated correctly when user has search history`() { ... }
  41. 4. Use descriptive test names From the test name, we

    should be able to tell why the test failed. @Test fun `search field is updated correctly when user has search history`() { ... }
  42. 4. Use descriptive test names From the test name, we

    should be able to tell why the test failed. @Test fun `search field is updated correctly when user has search history`() { ... } @Test fun `search field is updated with last search when user has search history`() { ... }
  43. 4. Use descriptive test names From the test name, we

    should be able to tell why the test failed. @Test fun `search field is updated correctly when user has search history`() { ... } @Test fun `search field is updated with last search when user has search history`() { ... }
  44. 4. Use descriptive test names Kotlin allows us to use

    to write test function names with spaces @Test fun `welcome dialog should be shown on first log in`() { // test goes here }
  45. 4. Use descriptive test names JUnit 5 allows to specify

    a custom display name for the test @Test @DisplayName("welcome dialog should be shown on first log in") void showWelcomeDialogOnFirstLogin() { // test goes here }
  46. 5. More tips • Avoid logic in your tests ->

    if/else, loops, etc. • Avoid abstractions in tests
  47. 5. More tips • Avoid logic in your tests ->

    if/else, loops, etc. • Avoid abstractions in tests • Be generous with comments
  48. 5. More tips • Avoid logic in your tests ->

    if/else, loops, etc. • Avoid abstractions in tests • Be generous with comments • Use parameterized tests