Нативная разработка мобильных приложений

Как писать и запускать интеграционные тесты
Как отмечалось выше, интеграционные тесты помогают убедиться в правиль
-
ной работе всего потока логики, а не отдельных логических единиц. Рассмот-
рим основные моменты на примере. Следующий тестовый класс использует 
библиотеки Robolectric и AndroidX для проверки экземпляра 
Context
и событий 
жизненного цикла:
Java
@RunWith(AndroidJUnit4.class)
@Config(shadows = {ShadowAsyncTask.class})
public class LoginAc ti vi tyTest {
private Ac ti vi ty mAc ti vi ty;
@Before
public void setup() {
Intents.init();
Ac ti vi tyScenario scenario = Ac ti vi tyScenario.launch(MyAc ti vi ty.class);
scenario.moveToState(Lifecycle.State.RESUMED);
scenario.onAc ti vi ty(activity -> mAc ti vi ty = activity);
}
@After
public void teardown() {
Intents.release();
mAc ti vi ty = null;
}
@Test
public void loginAc 
ti 
vi 
ty_whenLaunched_shouldShowRequiredControls() {
onView(withId(R.id.credentials)).check(matches(isDisplayed()));
onView(withId(R.id.submit)).check(matches(isDisplayed()));
}
}
Kotlin
@RunWith(AndroidJUnit4::class)
@Config(shadows = { ShadowAsyncTask::class })
class LoginAc ti vi tyTest {

---

Android 

221
private var activity: Ac 
ti 
vi 
ty? = null
@Before
fun setup() {
Intents.init()
val scenario = Ac ti vi tyScenario.launch(MyAc ti vi ty::class.java)
scenario.moveToState(Lifecycle.State.RESUMED)
scenario.onAc 
ti 
vi 
ty({ a ­> activity = a })
}
@After
fun teardown() {
Intents.release()
activity = null
}
@Test
fun loginAc 
ti 
vi 
ty_whenLaunched_shouldShowRequiredControls() {
onView(withId(R.id.credentials)).check(matches(isDisplayed()))
onView(withId(R.id.submit)).check(matches(isDisplayed()))
}
}
Рассмотрим подробнее этот код:
1) аннотация 
@RunWith
просто сообщает фреймворку тестирования, что мы 
используем механизм запуска тестов JUnit4;
2) аннотацию 
@Config
можно использовать для определения разнообразных 
конфигурационных параметров, и в данном случае мы указываем, что 
хотим использовать класс 
ShadowAsyncTask
. Предположим, что этот класс 
переопределяет поведение класса 
AsyncTask
, который по умолчанию соз
-
дает для задания новый поток выполнения и просто запускает задание 
в существующем потоке. То есть любые асинхронные операции, выпол
-
няемые с помощью 
AsyncTask
, будут выполняться синхронно и последо
-
вательно, поэтому проверить их работу будет намного проще;
3) аннотация 
@Before
перед методом 
setup
указывает, что он должен вы
-
зываться перед вызовом любого другого метода, осуществляющего тес-
тирование. В нашем методе 
setup
мы инициализируем класс 
Intents
из 
AndroidX, чтобы с его помощью перехватывать и исследовать получен
-
ные намерения и определить, приводит ли нажатие кнопки к отправке 
намерения для запуска какого-либо 
Ac ti vi ty
;
4) аннотация 
@After
играет противоположную роль – она отмечает метод, 
который должен вызываться после каждого теста. Здесь мы просто осво
-
бождаем экземпляр 
Intents
и удаляем экземпляр 
Ac ti vi ty
;
5) все методы, осуществляющие тестирование, должны отмечаться анно
-
тацией 
@Test
. Имя метода может показаться излишне громоздким, но 
оно следует соглашению «дано – когда – затем», благодаря этому мы 
можем различать функциональные части, которые на первый взгляд 
кажутся очень похожими. В этих конкретных тестах мы используем це
-
почечный синтаксис Espresso, чтобы убедиться в видимости пары эк
-
земпляров 
View
, обеспечивающих получение и отправку учетных дан
-
ных пользователя.

---

222

Тестирование
Обратите внимание, что в предыдущем примере мы используем Espresso 
API внутри локального, а не инструментированного теста. До появления An
-
droidX это было невозможно, и весь код Espresso мог выполняться только на 
фактических устройствах или в эмуляторах.
iOS
В Xcode встроены отличные инструменты поддержки тестирования в iOS. Тес-
ты в iOS подразделяются на две основные категории, модульные тесты и тес-
ты пользовательского интерфейса, причем тестирование пользовательского 
интерфейса напоминает автоматизированное интеграционное тестирование 
в зависимости от их настройки и выполнения. А теперь, без лишних слов, углу
-
бимся в разработку модульных тестов.