что такое модульный тест, в приложениях android

Мои приложения-это в основном GUIs, которые связываются с сервером для большей части своей информации. Если что-то пойдет не так, это обычно будет в сетевом вызове или неправильном предположении об объекте JSON.

модульные тесты не подходят для этих задач, связанных с сетью и вводом-выводом, иначе они не будут называться модульными тестами.

поэтому я пытаюсь собрать точку модульных тестов в моем случае. Зачем мне тестировать, может ли кнопка Android щелкнуть или EditText увидеть, что я тип? Я просто не понимаю полезности реализации этих утомительных тестов

private void initElements(){
    placeButton = (Button) findViewById(R.id.currplace);
    placeButton.setText(MainActivity.this.getString(R.string.findingLocation));
    placeButton.setEnabled(false);
    selectplaceLayout = (LinearLayout)findViewById(R.id.selectplaceLayout);
    selectplaceLayout.setVisibility(View.GONE);
    splash = (RelativeLayout)findViewById(R.id.splashbg);
    infoLayout = (LinearLayout)findViewById(R.id.infoLayout);
}

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

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

что я должен обнаружить, получив доступ к представлениям android, которые я уже знаю, я объявил и инициализировал? Я, должно быть, думаю об этом слишком ограниченно

Итак, проницательность оценили

15
android android-testing junit robotium unit-testing

2 ответов

в вашем вопросе много аспектов, но, на мой взгляд, вам, вероятно, не нужны модульные тесты в вашем проекте.

модульные тесты действительно сияют, когда вам нужно много бизнес-логики для вашего проекта. В этом случае вы, вероятно, захотите разделить свое приложение на несколько слоев (скажем, 3-уровневую архитектуру), чтобы, среди прочего, добавить некоторую естественную изоляцию для уровня бизнес-логики и покрыть ее сетью безопасности модульных тестов.

этой страховочная сетка покрывает вашу задницу во время рефакторинга бизнес-уровня, и это одна из главных вещей, которые вы из модульных тестов (TDD может предложить некоторые хорошие дополнительные побочные эффекты).

однако, это не все единороги и радуги и юнит-тест может стоить, а иногда они стоят много. Хорошие модульные тесты изолированы (т. е. имеют дело с небольшими кусками кода). Это означает, что вам нужно добавить слои абстракции, чтобы поставить свои классы под тест.

Это может положительно повлиять на ваш система или отрицательная. Расслоение делает вашу систему более гибкой со стоимостью повышенной сложности.

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

на основе вашего описания-ваше типичное приложение, как правило, в значительной степени уровень презентации для некоторых внешних серверов. Это не так много, кроме представления информации на Android-телефоне и превращает действия пользователя в команды на стороне сервера, где выполняется основная бизнес-логика (управление).

при таком подходе большая часть кода, который вы, вероятно, пишете, связана с "как отображать то и это" или"как сигнализировать серверу в том или ином случае". Такого рода код, очевидно, сильно зависит от платформы, и это означает, что если вы хотите поставить его под тест, вам придется издеваться над множеством Android-кода\поведения.

теперь Android-это несколько специфическая платформа. Он был разработан для оптимизации производительности и позволяет разработчикам быстро запускать и создавать приложения. Часто это означает некоторое количество классов "swiss-knife", которые вы используете\extend, и обычно это ускоряет написание кода, но издевательство над этими классами может стать реальным ад. Не говоря уже о том, что вы должны понимать, как платформа работает под капотом, чтобы сделать эти насмешки полезными. Другими словами, накладные расходы от проведения этого теста будут высокими.

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

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

В конце концов, чтобы ответить на ваш вопрос, который вы должны сначала ответьте на эти вопросы:

будет ли overdesign добавлять абстрактный слой, отделенный от платформы, в ваше приложение (похоже, в вашем случае это будет)? если да-не используйте модульные тесты - они только замедлят вас. Если нет-используйте их.

вы собираетесь много рефакторинга? если это большой проект с большим количеством кода и, следовательно, обслуживанием-вы, вероятно, будете, поэтому инвестируйте в многоуровневые и модульные тесты (но, на первый взгляд, это не кажется, что это ваш случай). Если это не ваш случай - не заморачивайтесь с юнит-тестами и идти быстро.

вам нужно много издеваться над платформой, чтобы написать модульные тесты? если да (кажется, ваш случай) - не пишите модульные тесты - они не стоят усилий.

надеюсь, это поможет.

20

с Android.Docs

для тестирования приложений Android вы обычно создаете следующие типы автоматизированных модульных тестов:

локальные тесты: модульные тесты, которые выполняются только на локальном компьютере. Эти тесты компилируются для локального запуска на виртуальной машине Java (JVM), чтобы минимизировать время выполнения. Используйте этот подход для запуска модульных тестов, которые не имеют зависимостей от Android framework или имеют зависимости, которые могут быть заполнены с помощью mock объекты.

инструментальные тесты: модульные тесты, которые выполняются на устройстве Android или в эмуляторе. Эти тесты имеют доступ к информации инструментария, например контекст для тестируемого приложения. Используйте этот подход для запуска модульных тестов с зависимостями Android, которые не могут быть легко заполнены с помощью макетных объектов.

Примечание: модульные тесты не подходят для тестирования сложных событий взаимодействия UI. Вместо этого следует использовать фреймворки тестирования пользовательского интерфейса, как описано в разделе автоматизация тестов пользовательского интерфейса.

0