|
Рис. 14.1
Каталоги с тестами в Android Studio
В первой папке будет находиться весь исходный код. В папке с меткой
(test) – модульные и интеграционные тесты. А в последней папке с меткой (an
-
droidTest) – тесты пользовательского интерфейса на основе Espresso, но о них
мы не будем рассказывать в этой главе.
Независимо от выбора языка для проекта, Java или Kotlin, дерево каталогов
проекта будет иметь одну и ту же структуру. Если потом вы добавите файлы
противоположного типа (например, в проект на Kotlin добавите файлы на Java
или наоборот), то обнаружите, что для каждого языка будет создан свой комп-
лект каталогов – по одному для исходного кода, модульных и интеграционных
тестов и тестов пользовательского интерфейса.
Как писать и запускать модульные тесты
Все тесты, основанные на JUnit и Robolectric, помещаются в каталог с меткой
(test), который далее мы будем называть просто «каталогом с тестами».
Открыв эту папку, вы обнаружите в ней готовый пример тестового класса
с именем ExampleUnitTest. Он импортирует базовые статические методы
as
sert
из JUnit и может включать какие-то элементарные проверки, например:
218
Тестирование
Java
public class ExampleUnitTest {
@Test
public void addition_isCorrect() {
assertEquals(4, 2 + 2);
}
}
Kotlin
class ExampleUnitTest {
@Test
fun addition_isCorrect() {
assertEquals(4, 2 + 2)
}
}
Это реализация простейшего модульного теста. Каждый модульный тест
проверяет одну функциональную единицу кода. В предыдущем примере мало
пользы, так как все проверяемые операторы находятся внутри самого теста,
поэтому давайте рассмотрим немного более полезный пример:
Java
public class Calculator {
public static add(int a, int b) {
return a + b;
}
}
Kotlin
fun add(a: Int, b: Int): Int {
return a + b
}
Протестировать этот простой класс можно с помощью следующего модуль
-
ного теста:
Java
public class CalculatorTest {
@Test
public void add_returnsCorrectValue_forPositiveValues() {
int expected = 4;
int actual = Calculator.add(2, 2);
assertEquals(expected, actual);
}
}
Kotlin
class AddTest {
@Test
fun add_returnsCorrectValue_forPositiveValues() {
val expected = 4
Android
219
val actual = add(2, 2)
assertEquals(expected, actual)
}
}
Обратите внимание, что методы
assert
принимают «фактическое» (
actual
)
значение, полученное логикой класса, и «ожидаемое» (
expected
), которое долж
-
на сгенерировать эта логика. Они сравнивают полученные значения, и если те
не совпадают (или не соответствуют результату, предполагаемому конкретны
-
ми версиями метода
assert
, такими как
assertTrue
или
assertFalse
), то просто
генерируют исключения, которые затем перехватываются фреймворком тес-
тирования и помогают определить, какие тесты пройдены успешно, а какие
потерпели неудачу.
Модульные тесты для процедурного кода, всегда возвращающего одинако
-
вые результаты в ответ на одни и те же входные данные, почти всегда уместны
и полезны. В случае с окружениями, основанными на состоянии (например,
в объектно-ориентированном программировании на Java и Kotlin), дело может
обстоять несколько сложнее.
Интегрируя свой код в платформу, такую как AOSP, разработчик полагает
-
ся на определенные возможности, классы и значения. Соответственно, тесты,
проверяющие этот код, могут стать более сложными, это особенно верно, ког
-
да дело доходит, например, до компонентов
Ac ti vi ty
или событий жизненно
-
го цикла. Именно по этой причине была создана библиотека Robolectric – она
обеспечивает возможность организации взаимодействий с подобными меха
-
низмами инфраструктуры простым и понятным способом.
Обратите внимание, что в настоящее время целью развития библиотеки
Robolectric является ее включение в общий фреймворк Android Test, и на по
-
следней конференции Google I/O, прошедшей перед публикацией этой книги,
многие выступавшие отмечали, что поддержку Android в Robolectric скоро за
-
менит идентичная поддержка из новых пакетов AndroidX. То есть привлече
-
ние AndroidX для тестирования имеет определенную ценность. Использова
-
ние синтаксиса Espresso для реализации локальных и инструментированных
тестов пользовательского интерфейса может дать огромные преимущества
любой команде, но в то же время некоторые нетривиальные ошибки, обнару
-
женные нами за год, помешали нашей команде полностью мигрировать на эту
библиотеку.
Когда тесты должны интегрироваться с другим кодом, особенно с малоиз
-
вестными наборами инструментов, такими как средства рисования пикселей
на экране в Android, вы действительно можете столкнуться с существенными
ограничениями. При написании тестов учитывайте целесообразность трудоза
-
трат. Вам часто будет встречаться термин «охват»; обычно под ним понимается
доля кода, охваченного тестированием, но на самом деле существует множест-
во самых разных способов оценки охвата – кто-то подсчитывает количество
строк со ссылками, кто-то подсчитывает инструкции и даже ветви условных
операторов. Если требуется обеспечить 100%-ный охват для нового продукта,
вам (и вашей команде), возможно, придется определить наилучший и наибо
-
лее практичный подход к тестированию. В зависимости от используемого у вас
определения термина «охват» может оказаться невозможным достичь 100 %
220
Тестирование
охвата. В предыдущем тесте, проверяющем работу метода
Calculator.add
, мож
-
но предположить, что достаточно одного (или нескольких) подобного теста,
и едва ли кто-то предложит проверить все возможные комбинации двух целых
чисел,
но
у вас может появиться желание проверить, что произойдет при сло
-
жении двух целых чисел, сумма которых превышает максимальное целочис
-
ленное значение в вашей системе, а также при сложении двух отрицательных
или нулевых значений. Как уже говорилось, вы и ваша команда должны опре
-
делить область тестирования, требования, охват и приемы, и они могут сильно
отличаться в разных организациях и даже в разных подразделениях внутри
организации.
Do'stlaringiz bilan baham: |
