Что тестировать с Robolectric?

Мне кажется, я в корне неправильно понимаю предназначение Robolectric. Я бьюсь с этим уже неделю, и пока что получение нового сообщения об ошибке считается прогрессом. Я могу протестировать некоторые базовые вещи, такие как статические представления в действии, но когда в игру вступают что-то более сложное, все просто разваливается. Мне пришлось расширить Robolectric для поддержки сторонних библиотек с определенными параметрами, панелями действий Appcompat и многими другими вещами, что отнимало чрезвычайно много времени и нигде не было задокументировано, и все продвигается довольно медленно. Я начинаю думать, что использую его неправильно, и он просто не должен делать то, что я хочу.

Общая логика приложения довольно проста, поэтому модульное тестирование не так уж много, самые сложные вещи находятся в пользовательском интерфейсе и удаленных вызовах API. Предполагается ли, что Robolectric просто сделает модульное тестирование для Android менее болезненным, чем с JUnit, потому что он может работать на JVM и поддерживает несколько классов Android? Возможно, для моих нужд больше подойдет фреймворк для тестирования поведения «черный ящик», такой как Espresso? Но мы используем непрерывную интеграцию, и Robolectric было удобно и легко настроить для запуска тестов на сервере CI, и я бы хотел, чтобы все так и оставалось.

Для чего вы используете Robolectric? Многие сообщения в блогах рекомендуют его для «тестирования жизненного цикла активности», но, поскольку я также новичок в мире Android, я не совсем понимаю его цель, тем более что приложение, которое я тестирую, предназначено только для портретной ориентации. . Может ли кто-нибудь дать обзор того, для чего вы используете Robolectric и как вы это делаете, желательно с примерами кода, и объяснить, почему и насколько важны эти тесты?


person p4sh4    schedule 08.12.2014    source источник
comment
Я думаю, вам было бы лучше на бирже программистов. Речь идет о концептуальных вопросах.   -  person cheffe    schedule 08.12.2014
comment
Спасибо за совет, но есть похожий вопрос там нет очень релевантных ответов, и он закрыт. Здесь я прошу больше о конкретных случаях использования, которые люди действительно используют с примерами кода.   -  person p4sh4    schedule 09.12.2014


Ответы (1)


Мы используем его для:

  • модульное тестирование: все компоненты от парсеров и утилит до контроллеров и презентаторов
  • интеграционное/приемочное тестирование: бизнес-логика приложения для каждого экрана (подпадает под интеграционное и/или приемочное тестирование)

Мы не используем его для (и обнаружили, что его трудно использовать для них):

  • тестирование сетевого уровня (мы запускаем все тесты, вводя тестовые данные так же, как и сетевой уровень; парсеры тестируются отдельно)
  • потоки пользователей через разные экраны

Если вы ищете больше последних, возможно, Espresso/Robotium лучше подходят для ваших нужд. И вы абсолютно можете запустить их как часть конвейера непрерывной интеграции, но вам потребуется потратить некоторое время на настройку или интеграцию с чем-то вроде Appurify.

Если вам очень сложно писать тесты, возможно, это связано с тем, как спроектировано ваше приложение, а не с тем, как вы используете robolectric. Посмотрите мой ответ здесь, он может вам помочь: Написание приемочных тестов Android с помощью robolectric: как это можно сделать?

person Alex Florescu    schedule 09.12.2014
comment
Хороший ответ, спасибо! Не могли бы вы подробнее рассказать о части пользовательских потоков - я использую Robolectric, чтобы проверить, запускается ли правильное действие/фрагмент при нажатии кнопки или событии, попадает ли оно в бизнес-логику приложения, для каждой категории экрана или пользовательских потоков категория? И не могли бы вы привести пример ваших модульных тестов контроллера и презентатора? - person p4sh4; 10.12.2014
comment
Легко проверить, что для некоторого действия на экране будет открыт другой экран. Я бы рекомендовал не тестировать два экрана одновременно (например, тестовый экран A, тестовый переход к экрану B, затем тестовый экран B), что вполне может быть допустимым пользовательским потоком. Это лучше сделать в тестах пользовательского интерфейса. - person Alex Florescu; 10.12.2014
comment
Ах да, я не тестирую два экрана одновременно. Тест по-прежнему не кажется истинным модульным тестом, потому что иногда он включает несколько методов из класса, но я определенно ограничиваю их максимум одним действием/фрагментом. - person p4sh4; 10.12.2014