Применяется ли YAGNI и при написании тестов?
Если у вас есть представление, которое хочет потреблять событие, вы можете использовать класс BaseInputConnection и его метод sendKeyEvent .
Чтобы использовать его, вы будете необходимо указать целевой вид (например, EditText), который получит KeyEvent. Например:
EditText editText;
BaseInputConnection inputConnection = new BaseInputConnection(editText, true);
inputConnection.sendKeyEvent(new KeyEvent(KeyEvent.ACTION_DOWN, KeyEvent.KEYCODE_POUND));
Результат этого походит на то, что пользователь на самом деле нажал клавишу # (при фокусировке текста редактирования).
11 ответов
Я думаю, что когда вы пишете метод, вы должны тестировать как ожидаемые, так и потенциальные пути ошибок. Это не означает, что вы должны расширять свой дизайн, чтобы охватить все возможные варианты использования - оставьте это на время, когда это необходимо, но вы должны убедиться, что ваши тесты определили ожидаемое поведение перед лицом неверных параметров или других условий.
YAGNI, как я понимаю, означает, что вы не должны разрабатывать функции, которые еще не нужны. В этом смысле вам не следует писать тест, который побуждает вас разрабатывать ненужный код. Однако я подозреваю, что вы спрашиваете не об этом.
В этом контексте меня больше беспокоит, стоит ли вам писать тесты, охватывающие неожиданные применения - например, ошибки из-за передачи нулевых или выходящих за пределы диапазона параметров - или повторения тестов, которые отличаются только данными, но не функциональностью. В первом случае, как я указал выше, я бы сказал да. Ваши тесты будут документировать ожидаемое поведение вашего метода перед лицом ошибок. Это важная информация для людей, использующих ваш метод.
В последнем случае я менее способен дать вам окончательный ответ. Вы, безусловно, хотите, чтобы ваши тесты оставались СУХИМИ - не пишите тест, который просто повторяет другой тест, даже если он имеет другие данные. В качестве альтернативы вы можете не обнаружить потенциальных проблем проектирования, если не воспользуетесь крайними случаями ваших данных. Простым примером является метод, вычисляющий сумму двух целых чисел: что произойдет, если вы передадите его maxint в качестве обоих параметров? Если у вас только один тест, тогда вы можете пропустить это поведение. Очевидно, это связано с предыдущим пунктом. Только вы можете быть уверены, действительно ли нужен тест.
Напишите тест так, как вам нужно. Тесты - это код. Написание кучи (изначально неудачных) тестов прерывает цикл «красный / исправление / зеленый» TDD и затрудняет выявление действительных сбоев по сравнению с незаписанным кодом.
Да YAGNI абсолютно применим к написанию тестов.
Например, я, например, не пишу тесты для проверки каких-либо свойств. Я предполагаю, что свойства работают определенным образом, и пока я не найду одно, которое делает что-то отличное от нормы, у меня не будет для них тестов.
Вы всегда должны учитывать обоснованность написания любого теста. Если написание теста не принесет вам явной пользы, я бы посоветовал вам этого не делать. Однако это явно очень субъективно , поскольку то, что, по вашему мнению, не стоит того, что кто-то может подумать, стоит затраченных усилий.
Кроме того, мог бы я написать тесты для проверки вводимых данных? Абсолютно. Однако я бы сделал это до точки . Скажем, у вас есть функция с 3 параметрами, которые являются целыми числами, и она возвращает значение типа double. Сколько тестов вы собираетесь написать для этой функции. Я бы использовал YAGNI здесь, чтобы определить, какие тесты принесут вам хороший ROI , а какие бесполезны.
Вы должны написать тесты для тех случаев использования, которые вы будут реализованы на этом этапе разработки.
Это дает следующие преимущества:
- Ваши тесты помогают определить функциональные возможности этого этапа.
- Вы знаете, когда вы завершили этот этап, потому что все ваши тесты проходят успешно. .
В идеале вы должны писать тесты, которые охватывают весь ваш код. В противном случае остальные ваши тесты потеряют ценность, и вы, в конце концов, будете отлаживать этот фрагмент кода повторно.
Итак, нет. ЯГНИ не включает тесты :)
Конечно, нет смысла писать тесты для тех случаев, когда вы не уверены, что они вообще будут реализованы - это должно быть очевидно для всех.
Для вариантов использования, которые, как вы знаете, будут реализованы, тестовые примеры имеют убывающую отдачу, то есть попытка охватить каждый возможный неясный угловой случай не является полезной целью, когда вы можете покрыть все важные и критические пути с половиной работы - при условии, конечно, цена упущения из виду редко возникающей ошибки непосильна; При написании программного обеспечения для авионики я бы определенно не согласился на меньшее, чем 100% покрытие кода и ветвей.
Вам, безусловно, следует воздержаться от написания тестовых примеров для функций, которые вы еще не собираетесь реализовывать. Тесты должны быть написаны только для существующей функциональности или функциональности, которую вы собираетесь внедрить.
Однако варианты использования - это не то же самое, что функциональность. Вам нужно только протестировать допустимые варианты использования, которые вы определили, но может произойти много других вещей, и вы хотите убедиться, что эти входные данные получат разумный ответ (который вполне может быть сообщением об ошибке) .
Очевидно, вы не получите всех возможных вариантов использования; если бы вы могли, не нужно было бы беспокоиться о компьютерной безопасности. Вы должны получить хотя бы более правдоподобные, и по мере возникновения проблем вам следует добавлять их в сценарии использования для тестирования.
Вы, вероятно, увидите здесь некоторую вариативность, но в целом цель написания тестов (для меня) - убедиться, что весь ваш код работает должным образом, без побочных эффектов, в предсказуемая мода и без дефектов. В таком случае, на мой взгляд, обсуждаемый вами подход к написанию тестов только для сценариев использования по мере их появления не принесет вам реальной пользы и на самом деле может причинить вред.
Что, если конкретный вариант использования для тестируемого модуля, который Вы игнорируете причины серьезного дефекта в конечном софте? Купило ли вам время, потраченное на разработку тестов, в этом сценарии что-нибудь, кроме ложного чувства безопасности?
(Для записи, это одна из проблем, с которыми я сталкиваюсь при использовании покрытия кода для «измерения» качества тестирования - это измерение, если оно низкое, может указывать на то, что вы недостаточно тестируете, но если он высокий, не следует полагать, что вы твердый как скала. Протестируйте общие случаи, крайние случаи, затем рассмотрите все «если», «а» и «но» модуля и проверьте их тоже.)
Мягкое обновление
Я должен отметить, что, возможно, я исхожу из другого перспектива, чем многие здесь. Я часто нахожу, что пишу код в стиле библиотеки, то есть код, который будет повторно использоваться в нескольких проектах для нескольких разных клиентов. В результате я, как правило, не могу с уверенностью сказать, что определенных вариантов использования просто не произойдет. Лучшее, что я могу сделать, это либо документально подтвердить, что они не ожидаются (и, следовательно, может потребоваться обновление тестов позже), либо - и это мое предпочтение :) - просто написать тесты. Я часто нахожу вариант №2 для более удобной повседневной жизни,
Я думаю, что ответ здесь, как и во многих местах, зависит от обстоятельств. Если в контракте, который представляет функция, указано, что она выполняет X, и я вижу, что с ней связаны модульные тесты и т. Д., Я склонен думать, что это хорошо протестированный модуль, и использовать его как таковой, даже если я не используйте его точно так же в другом месте. Если этот конкретный шаблон использования не протестирован, я могу получить запутанные или трудно отслеживаемые ошибки. По этой причине я считаю, что тест должен охватывать все (или большую часть) определенного, задокументированного поведения модуля.
Если вы решите тестировать более постепенно, я мог бы добавить в комментарии к документу, что функция «проверяется только для [определенных типов входных данных] результаты для других входных данных не определены ».
Я часто пишу тесты TDD для случаев, когда я не ожидаю, что вызовет нормальный поток программы. Подход «притворись, пока не сделаешь» заставляет меня начинать, как правило, с нулевого ввода - ровно настолько, чтобы иметь представление о том, как должен выглядеть вызов функции, какие типы будут иметь ее параметры и какой тип. возвращение. Для ясности, я не буду просто отправлять null функции в моем тесте; Я инициализирую типизированную переменную для хранения нулевого значения; Таким образом, когда Eclipse Quick Fix создает для меня функцию, она уже имеет правильный тип. Но не редкость, что я не ожидаю, что программа обычно отправит функции null. Итак, возможно, я пишу тест, который я AGN. Но если я начну со значений, иногда это слишком большой кусок. Я' m, разрабатывая API и продвигая его реальную реализацию с самого начала. Итак, начав медленно и притворяясь, пока не добьюсь успеха, иногда я пишу тесты для случаев, которые не ожидаю увидеть в производственном коде.
Если вы работаете в стиле TDD или XP, вы не будете ничего писать «заранее», как вы говорите, вы будете работать над очень точной частью функциональности на в любой момент, так что вы будете писать все необходимые тесты, чтобы убедиться, что часть функциональности работает так, как вы предполагаете.
Тестовый код аналогичен самому «коду», вы не будете писать код в заранее для всех вариантов использования вашего приложения, так зачем вам писать тестовый код заранее?