{"id":622,"date":"2022-07-06T15:26:00","date_gmt":"2022-07-06T15:26:00","guid":{"rendered":"https:\/\/androidpro.io\/?p=622"},"modified":"2023-12-21T09:10:43","modified_gmt":"2023-12-21T09:10:43","slug":"demock","status":"publish","type":"post","link":"https:\/\/androidpro.io\/demock\/","title":{"rendered":"De-mock your tests: practical recipes"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Examples of de-mocking test code as presented on Droidcon Berlin 2022.<\/p>\n\n\n\n

De-Mocking CRUD Service<\/h2>\n\n\n\n

Let’s consider a local database described by an interface:<\/p>\n\n\n\n

interface LocalDatabase {\n  fun save(list: List<ProductEntity>)\n  fun getAll(): List<ProductEntity>\n}\n<\/code><\/pre>\n\n\n\n
It can be implemented with SQL by Room, or with other database of your choice. To be honest, it could be even backend code with Postgres or Mongo. Doesn’t matter \u2013 we want to use some create some kind of test double for that database in unit tests.<\/p>\n\n\n\n
We are testing use case, that will<\/p>\n\n\n\n
    \n
  1. Fetch data from API if local DB is empty<\/li>\n\n\n\n
  2. Update local database<\/li>\n\n\n\n
  3. Return data<\/li>\n<\/ol>\n\n\n\n
      @Test\n  fun `given empty database when products fetched then update database`() {\n    val database = mockk<LocalDatabase> {\n      coEvery { getAll() } returns emptyList()\n    }\n\n    val someProducts = generateProducts(0..4)\n\n    val useCase = FetchDataUseCase(\n      database = database,\n      productsService = mockk {\n        coEvery { fetchProducts() } returns someProducts\n      }\n    )\n\n    useCase.execute()\n\n    coVerify { database.save(someProducts) }\n\n  }<\/code><\/pre>\n\n\n\n
    The test could look like this:<\/p>\n\n\n\n
      \n
    1. Create mock with MockK for LocalDatabase<\/li>\n\n\n\n
    2. Create mock for remote service (ProductsService)<\/li>\n\n\n\n
    3. Invoke system under test (execute use case)<\/li>\n\n\n\n
    4. Verify that database.save() was invoked<\/li>\n<\/ol>\n\n\n\n
      But… probably we will use that test database in other test scenarios.<\/p>\n\n\n\n
      How to de-mock that case?<\/p>\n\n\n\n
      Let’s create fake implementation for database using simple collection under the hood \u2013 List<>.<\/p>\n\n\n\n
      class FakeDatabase(\n  initialProducts: List<ProductEntity> = emptyList()\n) : LocalDatabase {\n\n  var products = initialProducts\n    private set\n\n  override suspend fun save(list: List<ProductEntity>) {\n    products = list\n  }\n\n  override suspend fun getAll(): List<ProductEntity> {\n    return products\n  }\n}<\/code><\/pre>\n\n\n\n
      Now we can refactor our test to something like this:<\/p>\n\n\n\n
        @Test\n  fun `given empty database when products fetched then update database`() {\n    val database = FakeDatabase(initialProducts = emptyList())\n\n    val someProducts = generateProducts(0..4)\n\n    val useCase = FetchDataUseCase(\n      database = database,\n      productsService = mockk {\n        coEvery { fetchProducts() } returns someProducts\n      }\n    )\n\n    useCase.execute()\n\n    database.products shouldBe someProducts\n\n  }<\/code><\/pre>\n\n\n\n
      And use regular assertion on fake database state \u2013 products kept as list inside fake instance.<\/p>\n\n\n\n
      Pros<\/h3>\n\n\n\n
        \n
      • possibility to reuse fake implementation across the tests<\/li>\n<\/ul>\n\n\n\n
        Cons<\/h3>\n\n\n\n
          \n
        • may be difficult to configure when we use more complex queries<\/li>\n<\/ul>\n\n\n\n
          De-Mocking single method interface, aka UseCase<\/h2>\n\n\n\n
          If we follow clean architecture guidelines (or just Single Responsibility Principle from SOLID), we may create class with single public method. That class could be described by an interface:<\/p>\n\n\n\n
          interface FetchArticlesUseCase{\n    suspend fun getData(): List<ArticleItem>\n}<\/code><\/pre>\n\n\n\n
          \n
          look \u2013 it’s suspend method!<\/p>\n<\/blockquote>\n\n\n\n
          How do we approach mocking that use case in our tests?<\/p>\n\n\n\n
          Let’s see how it could be done with Mockit:<\/p>\n\n\n\n
          val useCase = Mockito.mock(FetchArticlesUseCase::class.java)\nwhenever(useCase.getData()).thenReturn(generateItems(5))<\/code><\/pre>\n\n\n\n
          that won’t compile \ud83d\ude41<\/p>\n\n\n\n
          However Mockito doesn\u2019t have built-in support for stubbing suspend functions, so we may use MockK for that:<\/p>\n\n\n\n
          val useCase = mockk<FetchArticlesUseCase>{\n    coEvery { getData() } returns generateItems(5)\n}<\/code><\/pre>\n\n\n\n
          MockK can actually stub suspend and it works well. It has built-in methods coEvery<\/code> and coVerify<\/code> for coroutine support.<\/p>\n\n\n\n
          But how could we write this test double without mocking framework? We can just implement interface with object: Type{}<\/code> notation:<\/p>\n\n\n\n
          val useCase = object : FetchArticlesUseCase{\n    override suspend fun getData(): List<ArticleItem> {\n        return generateItems(5)\n    }\n}<\/code><\/pre>\n\n\n\n
          Well, that manual stub definition is not so clean but it works.<\/p>\n\n\n\n
          We can do it better.<\/strong><\/p>\n\n\n\n
          Add fun<\/code> to your interface to make it functional interface<\/em>:<\/p>\n\n\n\n
          fun interface FetchArticlesUseCase{\n    suspend fun getData(): List<ArticleItem>\n}<\/code><\/pre>\n\n\n\n
          fun interface<\/p>\n\n\n\n
          And now our manual stubbing may become shorter:<\/p>\n\n\n\n
          val useCase = FetchArticlesUseCase { \n    generateItems(5) \n}<\/code><\/pre>\n\n\n\n
          manual stubbing for fun interface<\/p>\n\n\n\n
          Pros<\/h3>\n\n\n\n
            \n
          • shorter syntax<\/li>\n\n\n\n
          • more control over stub configuration<\/li>\n\n\n\n
          • easy to throw errors inside lambda body<\/li>\n<\/ul>\n\n\n\n
            Cons<\/h3>\n\n\n\n
              \n
            • need to add fun interface <\/em>to your production code, and test design shouldn’t affect that much production code<\/li>\n<\/ul>\n\n\n\n
              De-Mocking side effects: Model-View-Presenter<\/h2>\n\n\n\n
              Side effects in code \u2013 usually functions that don’t return any real value (but change some internal state).<\/p>\n\n\n\n
                 interface View {\n        fun showList(items: List<ArticleItem>)\n        fun showError(message: String)\n        fun showLoading(loading: Boolean)\n    }\n\n    interface Presenter {\n        fun attach(view: View)\n        fun detach()\n        fun detailsClick(item: ArticleItem)\n    }<\/code><\/pre>\n\n\n\n
              MVP contract<\/p>\n\n\n\n
              The most straightforward way to test side-effects based code is by using verify<\/code> mechanisms from mocking framework.<\/p>\n\n\n\n
              val presenter = createPresenter(\n    fetchArticlesDataUseCase = mockk {\n        coEvery { execute() } returns someItems()\n    }\n)\n\nval view: View = mockk(relaxUnitFun = true)\n\n\npresenter.attach(view)\n\n\nverify {\n    view.showList(any())\n}<\/code><\/pre>\n\n\n\n
              given <\/strong>someItems returned by use case when <\/strong>view attached then <\/strong>display data on view.<\/p>\n\n\n\n
              However, that approach may not be perfect.<\/p>\n\n\n\n
              First of all, to have more complex assertion on items displayed on view, we would have to use matchers. <\/em>But what if we could use regular assertion for that?<\/p>\n\n\n\n
              Let’s dive into ViewRobot pattern:<\/p>\n\n\n\n
              class ViewRobot : View{\n\n    private val initialState: State = State()\n    val states: MutableList<State> = mutableListOf(initialState)\n\n    override fun showList(articleItems: List<ArticleItem>) {\n        states.add(states.last().copy(articleItems = articleItems))\n    }\n\n    override fun showError(message: String) {\n        states.add(states.last().copy(errorMessage = message))\n    }\n\n    override fun showLoading(loading: Boolean) {\n        states.add(states.last().copy(loading = loading))\n    }\n\n    data class State(\n        val articleItems: List<ArticleItem>? = null,\n        val errorMessage: String? = null,\n        val loading: Boolean? = null\n    )\n\n}<\/code><\/pre>\n\n\n\n
                \n
              1. We are describing view state by data class \u2013 holding every piece of data that is on that View.<\/li>\n\n\n\n
              2. View methods are copying actual state with some addition \u2013 add error message, toggle loading and so on<\/li>\n\n\n\n
              3. All states are kept in mutable list in ViewRobot<\/li>\n<\/ol>\n\n\n\n
                How test could look like with that approach?<\/p>\n\n\n\n
                val presenter = createPresenter(\n    fetchArticlesDataUseCase = mockk {\n        coEvery { execute() } returns someItems()\n    }\n)\n\nval view = ViewRobot()\n\npresenter.attach(view)\n\n\nview.states shouldContainExactly listOf(\n    State(),\n    State(loading = true),\n    State(loading = true, articleItems = items),\n    State(loading = false, articleItems = items)\n)<\/code><\/pre>\n\n\n\n
                So now the flow is:<\/p>\n\n\n\n
                  \n
                • Presenter asks UseCase\/Repository for data<\/li>\n\n\n\n
                • ViewRobot is attached to presenter<\/li>\n\n\n\n
                • Presenter invokes \u201edisplay\u201d methods on View<\/li>\n\n\n\n
                • ViewRobot state is updated<\/li>\n\n\n\n
                • Check: verify that ViewRobot has all required states<\/li>\n<\/ul>\n\n\n\n
                  Pros<\/h3>\n\n\n\n
                    \n
                  • that pattern can be used in MVP, MVVM, MVI<\/li>\n\n\n\n
                  • easier assertion on all View states (or just one state \u2013 doesn’t matter)<\/li>\n\n\n\n
                  • possibility to reuse view robot across Presenter\/ViewModel tests<\/li>\n<\/ul>\n\n\n\n
                    Cons<\/h3>\n\n\n\n
                      \n
                    • we are adding new layer of abstraction<\/li>\n<\/ul>\n\n\n\n
                      De-Mocking side effects: Callbacks<\/h2>\n\n\n\n
                      Imagine we have some kind of Router<\/em> in our app. It has method that will display dialog with two options \u2013 Ok and Cancel. We want to take different actions depending on option user chooses.<\/p>\n\n\n\n
                      interface Router {\n  fun showMessage(\n    onOkClick: () -> Unit,\n    onCancelClick: () -> Unit\n  )\n}<\/code><\/pre>\n\n\n\n
                      For simplicity our system under test will keep the “clicked” state:<\/p>\n\n\n\n
                      class ViewModel(router: Router) {\n  var tosAccepted: Boolean? = null\n\n  init {\n    router.showMessage(\n      onOkClick = {\n        tosAccepted = true\n      },\n      onCancelClick = {\n        tosAccepted = false\n      }\n    )\n  }\n}<\/code><\/pre>\n\n\n\n
                      ViewModel with Router<\/p>\n\n\n\n
                      How our test may look like with MockK?<\/p>\n\n\n\n
                      @Test\nfun `on ok clicked it should set tos = true`() {\n\n \n  val router: Router = mockk {\n    every { showMessage(any(), any()) } answers {\n      \/\/ simulate "ok" click\n      (firstArg() as (()->Unit)).invoke()\n    }\n  }\n\n\n  val viewModel = ViewModel(router)\n  \n  viewModel.tosAccepted shouldBe true\n}<\/code><\/pre>\n\n\n\n
                      Notice casting \u2013 in mockk definition we are using answer<\/strong> and then we are casting firstArg<\/strong> of that method (firs argument of showMessage method) to ()->Unit<\/code> function. It works, but it doesn’t look right.<\/p>\n\n\n\n
                      Let’s try to de-mock that mock and create FakeRouter:<\/p>\n\n\n\n
                      class FakeRouter(\n  val clickOk: Boolean = false,\n  val clickCancel: Boolean = false\n) : Router {\n  override fun showMessage(\n    onOkClick: () -> Unit,\n    onCancelClick: () -> Unit\n  ) {\n    if (clickOk) {\n      onOkClick.invoke()\n    }\n    if (clickCancel) {\n      onCancelClick.invoke()\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
                      We are instructing our FakeRouter which option should be clicked when showMessage()<\/code> is invoked. Simple conditional logic.<\/p>\n\n\n\n
                      Now our test may will look this way:<\/p>\n\n\n\n
                      @Test\nfun `on ok clicked it should set tos = true`() {\n\n  val router = FakeRouter(clickOk = true)\n\n  val viewModel = ViewModel(router)\n  \n  viewModel.tosAccepted shouldBe true\n}<\/code><\/pre>\n\n\n\n
                      test using FakeRouter<\/p>\n\n\n\n
                      Pros<\/h3>\n\n\n\n
                        \n
                      • type safety is kept \u2013 no need to cast firstArg()<\/code><\/li>\n\n\n\n
                      • easy to configure in other test cases \u2013 just change clickOk to false or add new conditional<\/li>\n<\/ul>\n\n\n\n
                        Cons<\/h3>\n\n\n\n
                          \n
                        • again, new layer of abstraction<\/li>\n\n\n\n
                        • if your router is large and you don’t split it into many interfaces, you’re gonna have a hard time<\/li>\n<\/ul>\n\n\n\n
                          \n","protected":false},"excerpt":{"rendered":"
                          Examples of de-mocking test code as presented on Droidcon Berlin 2022.<\/p>\n","protected":false},"author":1,"featured_media":624,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_eb_attr":"","footnotes":""},"categories":[1],"tags":[10],"class_list":["post-622","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-testing"],"yoast_head":"\nDe-mock your tests: practical recipes - Android Pro<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/androidpro.io\/demock\/\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"De-mock your tests: practical recipes - Android Pro\" \/>\n<meta property=\"og:description\" content=\"Examples of de-mocking test code as presented on Droidcon Berlin 2022.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/androidpro.io\/demock\/\" \/>\n<meta property=\"og:site_name\" content=\"Android Pro\" \/>\n<meta property=\"article:published_time\" content=\"2022-07-06T15:26:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-12-21T09:10:43+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/androidpro.io\/wp-content\/uploads\/2023\/09\/democking-recipes_o.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"512\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Jaros\u0142aw Michalik\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Jaros\u0142aw Michalik\" \/>\n\t<meta name=\"twitter:label2\" content=\"Estimated reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"4 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/androidpro.io\/demock\/\",\"url\":\"https:\/\/androidpro.io\/demock\/\",\"name\":\"De-mock your tests: practical recipes - Android Pro\",\"isPartOf\":{\"@id\":\"https:\/\/androidpro.io\/#website\"},\"datePublished\":\"2022-07-06T15:26:00+00:00\",\"dateModified\":\"2023-12-21T09:10:43+00:00\",\"author\":{\"@id\":\"https:\/\/androidpro.io\/#\/schema\/person\/1c52a058fc09bbdce9021f1d89d7f9d1\"},\"breadcrumb\":{\"@id\":\"https:\/\/androidpro.io\/demock\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/androidpro.io\/demock\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/androidpro.io\/demock\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/androidpro.io\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"De-mock your tests: practical recipes\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/androidpro.io\/#website\",\"url\":\"https:\/\/androidpro.io\/\",\"name\":\"Android Pro\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/androidpro.io\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-GB\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/androidpro.io\/#\/schema\/person\/1c52a058fc09bbdce9021f1d89d7f9d1\",\"name\":\"Jaros\u0142aw Michalik\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\/\/androidpro.io\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/708d1b2199cff06b8ce08b0b1acfaae2da833fe1b1e6c4ae84b8f73544c1b8d8?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/708d1b2199cff06b8ce08b0b1acfaae2da833fe1b1e6c4ae84b8f73544c1b8d8?s=96&d=mm&r=g\",\"caption\":\"Jaros\u0142aw Michalik\"},\"sameAs\":[\"https:\/\/androidpro.io\"],\"url\":\"https:\/\/androidpro.io\/author\/michalik-admin\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"De-mock your tests: practical recipes - Android Pro","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/androidpro.io\/demock\/","og_locale":"en_GB","og_type":"article","og_title":"De-mock your tests: practical recipes - Android Pro","og_description":"Examples of de-mocking test code as presented on Droidcon Berlin 2022.","og_url":"https:\/\/androidpro.io\/demock\/","og_site_name":"Android Pro","article_published_time":"2022-07-06T15:26:00+00:00","article_modified_time":"2023-12-21T09:10:43+00:00","og_image":[{"width":1024,"height":512,"url":"https:\/\/androidpro.io\/wp-content\/uploads\/2023\/09\/democking-recipes_o.png","type":"image\/png"}],"author":"Jaros\u0142aw Michalik","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Jaros\u0142aw Michalik","Estimated reading time":"4 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/androidpro.io\/demock\/","url":"https:\/\/androidpro.io\/demock\/","name":"De-mock your tests: practical recipes - Android Pro","isPartOf":{"@id":"https:\/\/androidpro.io\/#website"},"datePublished":"2022-07-06T15:26:00+00:00","dateModified":"2023-12-21T09:10:43+00:00","author":{"@id":"https:\/\/androidpro.io\/#\/schema\/person\/1c52a058fc09bbdce9021f1d89d7f9d1"},"breadcrumb":{"@id":"https:\/\/androidpro.io\/demock\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/androidpro.io\/demock\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/androidpro.io\/demock\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/androidpro.io\/"},{"@type":"ListItem","position":2,"name":"De-mock your tests: practical recipes"}]},{"@type":"WebSite","@id":"https:\/\/androidpro.io\/#website","url":"https:\/\/androidpro.io\/","name":"Android Pro","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/androidpro.io\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-GB"},{"@type":"Person","@id":"https:\/\/androidpro.io\/#\/schema\/person\/1c52a058fc09bbdce9021f1d89d7f9d1","name":"Jaros\u0142aw Michalik","image":{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/androidpro.io\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/708d1b2199cff06b8ce08b0b1acfaae2da833fe1b1e6c4ae84b8f73544c1b8d8?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/708d1b2199cff06b8ce08b0b1acfaae2da833fe1b1e6c4ae84b8f73544c1b8d8?s=96&d=mm&r=g","caption":"Jaros\u0142aw Michalik"},"sameAs":["https:\/\/androidpro.io"],"url":"https:\/\/androidpro.io\/author\/michalik-admin\/"}]}},"_links":{"self":[{"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/posts\/622","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/comments?post=622"}],"version-history":[{"count":4,"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/posts\/622\/revisions"}],"predecessor-version":[{"id":1373,"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/posts\/622\/revisions\/1373"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/media\/624"}],"wp:attachment":[{"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/media?parent=622"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/categories?post=622"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/androidpro.io\/wp-json\/wp\/v2\/tags?post=622"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}