Написан модульный тест для тестирования rxjava, но не уверен, что мой модульный тест тестирует все - PullRequest
Новая
       18

Написан модульный тест для тестирования rxjava, но не уверен, что мой модульный тест тестирует все

0 голосов
/ 27 декабря 2018 
Android Studio 3.4

У меня есть следующий метод, который я тестирую.По сути, этот тест делает запрос и возвращает LoginResponseEntity, который будет отображен и возвращает Single<LoginResponse>

 override fun loginUserPost(username: String, password: String, uniqueIdentifier: String, deviceToken: String, apiToken: String) : Single<LoginResponse> {
            val loginRequestEntity = LoginRequestEntity(username, password, uniqueIdentifier, deviceToken)
            return loginAPIService.loginUserPost(loginRequestEntity, apiToken)
                .map {
                    loginResponseDomainMapper.map(it)
                }
    }

Тестовый пример, который я написал, работает, но я думаю, что этоне полностью тестирует этот метод. 

     @Test
     fun `should return LoginResponse`() {
        val loginRequestEntity = LoginRequestEntity("username", "password", "uniqueidentifier", "devicetoken")
        val loginResponse = LoginResponse("token", createUser(), emptyList(), emptyList())
        val loginResponseEntity = LoginResponseEntity("token", createUserEntity(), emptyList(), emptyList())

        whenever(loginAPIService.loginUserPost(loginRequestEntity, "apitoken")).thenReturn(Single.just(loginResponseEntity))

        loginServiceImp.loginUserPost("username", "password", "uniqueidentifier", "devicetoken", "apitoken")
            .test()
            .assertValue(loginResponse)

        verify(loginAPIService).loginUserPost(loginRequestEntity, "apitoken")
    }

        private fun createUser() =
            User(
                "id",
                "email",
                "firstname",
                "lastname",
                "phone",
                "address",
                "dob",
                "customer",
                listOf("enterpriseids"),
                listOf("vendorids"))

        private fun createUserEntity() =
            UserEntity(
                "id",
                "email",
                "firstname",
                "lastname",
                "phone",
                "address",
                "dob",
                "customer",
                listOf("enterpriseids"),
                listOf("vendorids"))
    }

Могу ли я сделать еще что-нибудь, чтобы протестировать этот метод.Должен ли я тестировать .map{loginResponseDomainMapper.map(it) часть этого метода?

Ответы [ 2 ]

0 голосов
/ 04 января 2019

Вы можете добавить тесты для неудачных сценариев:

1) Если loginUserPost не удается, вы можете добавить: 

whenever(loginAPIService.loginUserPost(any(), any())).thenReturn(Single.error(Exception()))
...
   .test()
   .assertError(...)

2) Если loginResponseDomainMapper не удалось, вы можете добавить:

whenever(loginResponseDomainMapper.map(any())).thenThrow(Exception())
...
       .test()
       .assertError(...)

Таким образом, вы можете проверить неуспешное / успешное отображение и вывод функции, не вдаваясь в подробности.loginResponseDomainMapper поведение должно быть проверено в рамках его собственных модульных тестов.

0 голосов
/ 02 января 2019

Это действительно маленький метод и не содержит много вещей для тестирования.Две внешние зависимости (loginAPIService и loginResponseDomainMapper) сокращают количество проверяемых объектов.

Итак,

1) loginResponseDomainMapper не является частью тестируемого метода и также долженНасмехайся.

2) Ты должен понять, что здесь нужно тестировать.

  • Во-первых: проверьте, правильно ли был построен LoginRequestEntity и передан методу loginUserPost.Это делается с помощью verify(loginAPIService).loginUserPost(loginRequestEntity, "apitoken") звонка.Кроме того, вы можете использовать ArgumentCaptor.
  • Секунда: Выход метода loginUserPost был правильно передан методу loginResponseDomainMapper.map.Это можно сделать с помощью дополнительного вызова verify, как и ранее.
  • В-третьих: Вывод метода map был возвращен правильно.Это делается с помощью assertValue call.

Итак, вы просто пытаетесь проверить, что поток данных был верным и ничего не было изменено во время выполнения инопланетянами или что-то в этом роде.

3) Отрицательное тестирование.Есть также не так много вещей, которые могут пойти не так.Если loginUserPost не имеет аннотации @NotNull, лучше обработать null результат этой функции.
Кроме того, что если запрос был неверным?Пароль был неверный или apitoken истек?Я считаю, что это не приведет к печальным последствиям, но вы должны об этом подумать.

...