Ключевой вопрос, который нужно задать, — это то, что вы хотите получить от своих тестов. Я уже говорил о том, что, на мой взгляд, цель тестирования — найти информацию, а затем передать эту информацию. Это здорово и все такое … но … что вы на самом деле хотите получить от самих тестов?То, как вы ответите на этот вопрос, в значительной степени повлияет на вашу функцию тестирования, особенно когда речь идет о выборе вспомогательных инструментов, например, для управления тестированием или автоматизации тестирования.
Не проверяйте, что он делает то, что делает…
Это, наверное, звучит очевидно, но я все равно скажу: тест не должен просто проверять, что что-то делает то, что оно делает. В конце концов, то, что он делает, может быть неправильным. Немного более формальный способ сказать это — проверить намерение, а не реализацию.
Я думаю, действительно важно помнить, что тест в значительной степени бессмыслен как проверка качества пользовательского интерфейса или кода, если этот тест воспроизводит только то, что делает пользовательский интерфейс или код. Я говорю это потому, что любые ошибки, которые нашли свой путь в пользовательском интерфейсе или в коде, будут просто воспроизведены в тесте. В частности, в случае модульных тестов на основе кода тесты, которые просто копируют код, очень опасны, потому что они дают вам ощущение комфорта, думая, что код протестирован правильно, в то время как на самом деле они просто говорят то же самое неправильно, но немного по-другому. Кстати, тесты онлайн доступны на страницах специализированного сайта.
Аналогично, хорошая операционная эвристика — избегать написания тестов, глядя на пользовательский интерфейс или код, поскольку вы можете быть ослеплены деталями реализации. Это одна из причин, почему тесты лучше писать до кода, а не после. И это может относиться к уровню приложений и уровню кода. Это также может относиться к понятию написания тестов как спецификаций и наоборот.
Я видел много сред, в которых какие-либо спецификации просто не собирались писать для данной части функциональности. Итак, тестировщики просто взяли предоставленную им сборку и написали тесты вокруг того, что делает приложение. Хотя вы можете утверждать, что это “быть гибким”, или “быть проворным”, или “просто выполнять работу”, это неэффективная практика тестирования.
Намерение против Реализация
Я привел эту идею тестирования к цели выше, поэтому я хочу немного поговорить об этом. Понятие “намерения” (что предназначено для приложения) и “реализации” (что на самом деле делает приложение) может служить хорошим организующим принципом для широкого круга задач тестирования.
В качестве примера, вместо того, чтобы свободно смешивать тесты pass / fail с какой-либо логикой автоматизации пользовательского интерфейса, вероятно, было бы эффективнее разделить ваши проблемы. Тесты, в которых говорится, что должно делать приложение, находятся в другом месте, чем логика “приспособления”, в которой говорится, как приложение должно это делать. Итак, если у вас есть такое мышление, это должно стать основой для вашего выбора возможных инструментов. В конце концов, некоторые инструменты просто не позволяют вам этого делать. Или они позволяют вам это делать, но только очень громоздким способом.
Ваши тесты также предназначены для обеспечения основы для проверки требований, в каком бы формате они ни были. Итак, то, что люди часто называют “тестами”, на самом деле является “примерами” того, как должен вести себя фрагмент кода — или набор функциональных возможностей. На уровне кода вы в конечном итоге сталкиваетесь с такими практиками, как разработка, основанная на тестировании (TDD), но преемники TDD действительно представляют для меня больший интерес: разработка, основанная на примерах, и разработка, основанная на поведении. На самом деле здесь основное внимание уделяется тестам, которые называются “примерами” или “поведением”, в качестве фрагментов беседы. На самом деле, вы можете думать о “специфическом поведении”, “наборах примеров”, “использовании приложений” и “тестах” как об одних и тех же вещах. Но вот вопрос: выбрали ли вы инструмент, который позволит вам относиться к ним как к одним и тем же вещам? Что еще более важно, выбрали ли вы практику, которая позволит вам проводить эти различия недвусмысленным способом, который можно легко объяснить любому?
Вместо того, чтобы слишком углубляться в обсуждение инструментов или практики, я хочу сосредоточиться на том, для чего нужны тесты, рассматривая тесты в конкретном контексте: тестирование, основанное на принятии.
Приемочные тесты
В предыдущем посте я говорил о том, что приемочные тесты — это именно тесты. Итак, здесь я собираюсь привести несколько примеров того, о чем я говорю, когда использую термин “принятие” и связываю его с понятием “история”, которым часто разбрасываются, особенно в местах, которые называют себя “гибкими”. Каждый пример будет содержать несколько строк “AT”, которые обозначают “Приемочный тест”. После каждого примера я буду указывать некоторые “Моменты, на которые следует обратить внимание”. Не беспокойтесь слишком сильно о формате; вместо этого давайте просто сосредоточимся на содержании.