Что делать до unit test, в приложениях для Android

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

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

SO Я пытаюсь собрать точку Unit Tests в моем случае. Зачем мне проверять, может ли кнопка 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, то я знаю, что приложение работает. A unit test этого было бы лишним временем для создания. Занимает много времени, потому что я не знаком со всеми методами в платформе тестирования jUnit и Android.

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

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

поэтому, понимание было оценено

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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