Часто, для того чтобы понять, какие преимущества даёт тот или иной инструмент, полезно посмотреть, как те же задачи решались раньше. Поэтому, прежде чем говорить о матчерах, давайте посмотрим на эволюцию способа написания тестовых проверок.
Итак, сначала был просто if:
if (!condition) {
throw new Exception("Some really terrible error happened");
}Эта ужасная конструкция всем мозолила глаза: во-первых, она занимает целых три строчки, а во-вторых, нужно следить чтобы везде использовался один и тот же тип exception’ов (чтобы можно было их корректно обрабатывать). Кажется логичным спрятать это внутрь одной функции, которой можно передать условие и сообщение. Так появился метод assertTrue:
assertTrue("OMG, my condition had failed!", condition);Что ж, уже неплохо. Однако булево условие вещь не очень гибкая и порой получаются довольно громоздкие условия. Как следствие, стали появляться различные мутации assert’а: assertFalse, assertNull, assertNotNull, assertEquals и т.д. Как видите, каждый из этих методов начинается со слова assert – т.е. мы выполняем некую проверку и бросаем исключение если она не выполнена. Вторая же часть имени описывает саму проверку. Понятно, что проверок может быть бесконечно много, поэтому дальше плодить assert’ы слегка бессмысленно. Хорошо бы иметь один метод, в который можно передать некую абстрактную проверку, описанную стандартным образом. Такой проверкой и является матчер. Я думаю довольно очевидно, какие плюсы даёт такой подход – это действительно большой шаг вперёд (как при переходе от if’ов к assert’ам). А подробнее о преимуществах использования матчеров – в следующих постах.
comments powered by Disqus