В прошлых постах я рассказывал, как появились матчеры и почему их стоит использовать. Сегодня речь пойдёт о реализации своего матчера.
Прежде всего подумай, действительно ли тебе это нужно . Если ответ всё еще да – я научу тебя по-максимуму переиспользовать уже готовые матчеры. Как правило, проверка какого-либо сложного объекта заключается в получении простого свойства этого объекта и его проверке. Простой пример: ты тестируешь приложение, посылая http-запросы. Тебе нужно проверять, что на все запросы отдаётся ответ 200. Без использования кастомных матчеров, эта проверка будет выглядеть примерно так:
А вот такой мне бы хотелось её видеть:
Минимальная реалзиация матчера hasResponse будет при этом такой:
Вся магия прячется в имплементации FeatureMatcher, которую мы создаём. Точнее – в методе featureValueOf, который выделяет простое свойство у сложного объекта и передаёт его дальше для проверки. Кроме того, мы передаём в конструктор FeatureMatcher’a две строки – сообщение для expected и actual объектов. При фейле проверки, эти строки автоматически “приклеются” к проверке:
Поскольку мой матчер принимает на вход Matcher
При этом мне не нужно придумывать сообщение об ошибке, оно сформируется само:
Итак, идея FeatureMatcher – выделить простое свойство, описать его и проверить соответствующим готовым матчером. Просто и эффективно!
comments powered by Disqus