Настольная библиотека для тестирования Android-приложения, работающего в режиме реального времени.

Я написал приложение реального времени для Android, которое получает сотни входных событий в секунду и выдает несколько выходных событий в секунду. Входные события управляют конечными автоматами для создания выходных событий. Я записываю как входные, так и выходные события в файл для каждого запуска. Я хочу использовать файлы прогонов, которые я считаю допустимыми для регрессионного тестирования. Я передам записанные входные события в систему и буду искать ожидаемые выходные события.

Моя система получает события через цикл/обработчик и использует таймеры, но в остальном она не зависит от Android API, за исключением android.util.log для целей отладки, которые я могу легко обернуть.

Какой настольный фреймворк предоставит мне необходимые мне API? Будет ли достаточно теста JUnit? Должен ли это быть инструментальный тест? Мне действительно нужно запускать какую-то мокер-библиотеку? Это мое первое приложение для Android, и я все еще не освоился.

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

Я думаю, что вижу, как написать еще одно приложение для Android, которое бы выполняло эту работу, но это выглядит намного сложнее, чем делать это из оболочки, и к тому же это было бы намного менее удобно в использовании. Мой план резервного копирования состоит в том, чтобы протестировать мою систему ниже API петлителя (общедоступный API моей библиотеки) с использованием обычного обмена сообщениями потока Java. (Я хочу передавать события в систему в их исходное время.)

Обновление: когда я искал ответ, стало ясно, что я мог бы написать тест JUnit, который запускает все мои тесты в реальном времени, но меня беспокоят жалобы на медленную эмуляцию. Время имеет решающее значение во время этих испытаний. С другой стороны, настольный компьютер может запускать фоновые процессы, которые мешают синхронизации, поэтому, возможно, мне придется создать тестовую программу, которая запускается на устройстве. Надеюсь на совет...


person Joe Lapp    schedule 12.01.2017    source источник
comment
Есть ли что-нибудь в вашем приложении, что нужно протестировать с устройства? Если нет, вы можете просто написать тесты JUnit, которые запускаются на JVM. Поскольку вы не используете Android API, вам не нужно запускать эмулятор и проводить какие-либо инструментальные испытания.   -  person nicobatu    schedule 13.01.2017
comment
Спасибо! В основном меня беспокоит обмен сообщениями с лупером. Все остальное могу заглушить, если надо.   -  person Joe Lapp    schedule 13.01.2017
comment
Чтобы уточнить, эта система реального времени предоставляет API для использования приложением. Я хочу протестировать этот API. Если мне нужно обойти Looper, я не буду тестировать API, работа которого должна быть гарантирована. Не идеально.   -  person Joe Lapp    schedule 13.01.2017
comment
Robolectric эмулирует Looper и Handler, но очевидно, не работает для пользовательских экземпляров. Я посмотрю, как написать свою собственную эмуляцию Looper/Handler.   -  person Joe Lapp    schedule 13.01.2017
comment
Почему нельзя протестировать на реальном устройстве ваш API? Насколько я понимаю, вы хотите передать своей системе известную входную полезную нагрузку, следить за ожидаемым результатом и убедиться, что все это работает в течение определенного интервала времени. Это тот случай, когда тестирование пользовательского интерфейса + счетчики производительности и инициализация ввода данных должны произойти для подтверждения успеха. Нет?   -  person Paul Bruce    schedule 16.01.2017
comment
Хороший вопрос. Это вариант, но менее выгодный для меня. Между входами и выходами нет петли обратной связи, за исключением относительно медленного пользователя, поэтому обработка вывода может занять некоторое время. Мне просто нужно проверить логику. Я надеюсь, что смогу запустить несколько тестов одновременно на быстром компьютере, потому что последовательное выполнение всех тестов займет много времени. Кроме того, я ожидаю меньше работы по созданию гибкого инструмента командной строки, чем гибкий пользовательский интерфейс Android. (Я перевожу пользовательские жесты в пользовательские запросы.)   -  person Joe Lapp    schedule 17.01.2017
comment
Кроме того, в качестве обновления я планирую переключить свой код на использование android.os.HandlerThread, чтобы я мог заглушить этот класс, а не цикл, последний из которых должен каким-то образом подвешивать данные в любом потоке, из которого он запускается. Я реорганизую код для этого сейчас.   -  person Joe Lapp    schedule 17.01.2017
comment
С другой стороны, возможна ситуация, когда задержка между вводом и выводом становится неприемлемой для пользователя, или задержка вывода может достигать неприемлемого уровня на определенных устройствах. Вы правы, мне нужно было бы запустить тесты для этого на самом устройстве. Так что мне понадобится возможность запустить хотя бы нагрузочные тесты на устройстве. Хм... Надо подумать, как это меняет ситуацию для меня. Спасибо!   -  person Joe Lapp    schedule 17.01.2017
comment
Кроме того, как вы заметили, мне понадобится сквозное тестирование устройства. Итак, я должен поддерживать воспроизведение на устройстве в любом случае. Хм...   -  person Joe Lapp    schedule 17.01.2017
comment
Обновление: я написал библиотеку классов для эмуляции Looper при тестировании в реальном времени на рабочем столе. Это работает, но мне нужно реорганизовать интерфейс, чтобы обеспечить реалистичное тестирование в реальном времени на рабочем столе, поэтому я еще не знаю, устранил ли я все проблемы, связанные с реальным временем, которые могут возникнуть.   -  person Joe Lapp    schedule 27.01.2017