Сегодня несколько простых правил по использованию assert’ов в тестах.
Правило №1: Один тест – один assert. С одной стороны, кажется логичным проверять всё подряд по ходу выполнения тестов. Однако такое поведение свойственно людям, а не роботам, т.к. люди замечают любые отклонения от поведения системы. Роботы же замечают только те отклонения, которые их запрограммировали замечать. Как вы понимаете, запрограммировать проверять все отклонения невозможно, поэтому не стоит засорять ваши тесты лишними проверками – размазывается цель теста. А цель теста – проверка конкретного кусочка функционала, для этого достаточно одного assert’a в конце.
Правило №2: Assert – последнее, что делается в тесте. Дело в том, что если тест упадёт на assert’e – код, который идёт после него, не выполнится (а вы, очевидно, рассчитывали на его выполнение). Как правило в конец теста помещают какие-то действия по очистке тестовых данных, освобождению ресурсов и т.п. Именно для таких действий умные ребята придумали в junit аннотации @After и @AfterClass для методов, а так же механизм правил (@Rule). Поскольку assert – это точка принятия решения о прохождении/не прохождении теста, вы должны получать максимум информации в случае, если тест не прошёл.
Правило №3: Используй силу assertThat вместо assertTrue. При использовании assertTrue вы получаете диагностику вида expected: true, but was: false. Из-за этого приходится самостоятельно формировать сообщение об ошибке, чтобы в отчётах было понятно, что именно сломалось. При использовании assertThat и матчеров весь головняк по диагностированию ошибки перекладывается на матчер и вы получаете максимум информации при минимуме усилий.
Если вам есть что добавить или вы хотите оспорить применимость этих правил – вэлкам в twitter @art_koshelev.
comments powered by Disqus