Comments 40
Как можно догадаться по апельсину, что речь пойдет об автоматическом тестировании?
Сегодня только начал изучать unit-тесты. Так что статья очень вовремя! Буду писать сразу правильно.
Это прекрасно! Советую так же сразу ознакомиться с технологией рул (Rule) в JUnit. Тоже очень мощный и полезный инструмент.
Не стоит хвататься за такой мощный инструмент сразу. Начните с элементарных тестов:
Когда пишете тесты думайте о том, кто их будет поддерживать. Делайте все прямолинейно императивно и последовательно. Даже списки проверяйте константной индексацией:
public void testOrangeIsRounded() {
Fruit fruit = new Orange();
assertEquals(Shape.ROUNDED, fruit.getShape());
}
public void testOrangeIsOrange() {
Fruit fruit = new Orange();
assertEquals(Color.ORANGE, fruit.getColor());
}
public void testOrangeIsSweat() {
Fruit fruit = new Orange();
assertTrue("The fruit was not sweet as it MUST be.", fruit.isSweat());
}
Когда пишете тесты думайте о том, кто их будет поддерживать. Делайте все прямолинейно императивно и последовательно. Даже списки проверяйте константной индексацией:
public void testAllFruitsInBasketIsRounded() {
List<Fruit> fruits = basket.getFruits();
assertEquals(3, fruits.size()); // In tests you always know how many
assertEquals(Shape.ROUNDED, fruits.get(0).getShape());
assertEquals(Shape.ROUNDED, fruits.get(1).getShape());
assertEquals(Shape.ROUNDED, fruits.get(2).getShape());
}
С вами полностью согласен.
Тесты в какой-то мере должны служить документацией к коду. То что Вы написали в качестве примера элементарного кода, на самом деле выглядит очень просто и читабельно.
Тесты в какой-то мере должны служить документацией к коду. То что Вы написали в качестве примера элементарного кода, на самом деле выглядит очень просто и читабельно.
В какой мере тесты должны служить документацией можно понять из идеологии XP. Там довольно гармоничное использование Историй и Тестов. Истории первичны, кратки и ясные, а тесты «подпирают» все важные нюансы и частные случаи.
Иногда мне приходилось встречать тесты, которые пытались подменить собой истории:
Увы, эта практика плохо работает. Из-за сильного формализма ЯП, теряется возможность править истории вслед за изменением видения системы заказчиком или потребителями (и со скоростью этих изменений). Так что не стоит «документировать» систему тестами. Документируйте историями, а тестами проверяйте корректность работы системы по мере ее развития.
Иногда мне приходилось встречать тесты, которые пытались подменить собой истории:
@Test
public void as3OrangeBuyerIMustFound3RoundedFruitsInMyBasket() {
...
}
Увы, эта практика плохо работает. Из-за сильного формализма ЯП, теряется возможность править истории вслед за изменением видения системы заказчиком или потребителями (и со скоростью этих изменений). Так что не стоит «документировать» систему тестами. Документируйте историями, а тестами проверяйте корректность работы системы по мере ее развития.
Отвечу по-порядку:
1. Несмотря на мощность этого инструмента, он очень легок в освоении и использовании. Поддерживать тесты с его использованием становится гораздо проще, чем без него, когда количество тестов переваливает через некоторое количество. Ведь логика тестов отделена от логики получения конкретного значения от объектов — яйца в одной корзине, курицы в другой.
2. Что делать, если понадобится проверить все оранжевые круглые фрукты на количество долек, если неизвестно — будет ли следующий фрукт делиться на дольки? Будет тест на круглость, будет тест на оранжевость. Предположим они провалились — как избежать лишнего выполнения третьего теста? Использовать assume механизм. Если его не использовать, а продублировать первые два теста в начале третьего — то получим сразу 2 проблемы:
— дублирование кода — нужно ведь получать свойство и сообщать о нем так же как и в первых тестах.
— шум от проваленного теста. Зачем нам 2 теста, которые провалятся с сообщением о том, что фрукт не оранжевый? Это будет ясно и из первого проваленного теста. А представьте, что таких тестов будет в 10 раз больше, или в 100. Просматривать результат в котором провалилось 100 тестов вместо 2х очень тяжело и непонятно куда бежать и что делать.
3. Правильная мысль — думайте о том, кто будет поддерживать тесты: когда тест написан человеческим языком, в него гораздо проще въехать, а значит правильно распознать сценарий и изменить только необходимые части, не переписывая с 0 весь тест.
4. Правильная мысль — делайте все последовательно. Только начинайте со сценария теста — пишите что вы хотите проверить, а дальше вводите в дело матчеры, в которые и выносите логику получения свойства из объектов. В дальнейшем не придется менять тесты в которых вы используете свойство этого объекта для проверки — придется немного подправить матчер.
5. Абсолютно не согласен с проверкой списков константной индексацией. Я вижу три одинаковых строчки, с различием только в индексе. С матчером это будет одна строка, с полным соответствием смыслу проверки. Стоит только представить как при таком подходе будет расти копипаста, если таких тестов будет несколько, а список вдруг внезапно вырастет на пару элементов.
С матчером это будет выглядеть так:
6. Многие ставят в пример то, как удобно формировать свое сообщение при использовании assertTrue. Но ведь никто не отменяет такой возможности и при assertThat! Просто в большинстве случаев этого делать уже не приходится — правильный матчер все сформирует сам
1. Несмотря на мощность этого инструмента, он очень легок в освоении и использовании. Поддерживать тесты с его использованием становится гораздо проще, чем без него, когда количество тестов переваливает через некоторое количество. Ведь логика тестов отделена от логики получения конкретного значения от объектов — яйца в одной корзине, курицы в другой.
2. Что делать, если понадобится проверить все оранжевые круглые фрукты на количество долек, если неизвестно — будет ли следующий фрукт делиться на дольки? Будет тест на круглость, будет тест на оранжевость. Предположим они провалились — как избежать лишнего выполнения третьего теста? Использовать assume механизм. Если его не использовать, а продублировать первые два теста в начале третьего — то получим сразу 2 проблемы:
— дублирование кода — нужно ведь получать свойство и сообщать о нем так же как и в первых тестах.
— шум от проваленного теста. Зачем нам 2 теста, которые провалятся с сообщением о том, что фрукт не оранжевый? Это будет ясно и из первого проваленного теста. А представьте, что таких тестов будет в 10 раз больше, или в 100. Просматривать результат в котором провалилось 100 тестов вместо 2х очень тяжело и непонятно куда бежать и что делать.
3. Правильная мысль — думайте о том, кто будет поддерживать тесты: когда тест написан человеческим языком, в него гораздо проще въехать, а значит правильно распознать сценарий и изменить только необходимые части, не переписывая с 0 весь тест.
4. Правильная мысль — делайте все последовательно. Только начинайте со сценария теста — пишите что вы хотите проверить, а дальше вводите в дело матчеры, в которые и выносите логику получения свойства из объектов. В дальнейшем не придется менять тесты в которых вы используете свойство этого объекта для проверки — придется немного подправить матчер.
5. Абсолютно не согласен с проверкой списков константной индексацией. Я вижу три одинаковых строчки, с различием только в индексе. С матчером это будет одна строка, с полным соответствием смыслу проверки. Стоит только представить как при таком подходе будет расти копипаста, если таких тестов будет несколько, а список вдруг внезапно вырастет на пару элементов.
С матчером это будет выглядеть так:
assertThat(fruits, everyItem(hasShape(Shape.ROUND)));
6. Многие ставят в пример то, как удобно формировать свое сообщение при использовании assertTrue. Но ведь никто не отменяет такой возможности и при assertThat! Просто в большинстве случаев этого делать уже не приходится — правильный матчер все сформирует сам
Спасибо за обстоятельный ответ. Я пожалуй также по пунктам поддержу дискуссию.
1. Первый пункт полностью голословный. Я сомневаюсь, что можно найти объективную количественную оценку, чтобы сказать, сказать что assertThat лучше чем assertEquals.
2. «Что делать, если потребуется… если неизвестно будет ли...» — это выражения НЕ для тестов. В тестах проверяются только 100% известные и конкретные факты.
Добавляете в систему Orange, и считаете что он должен делиться на дольки — пишете тест, который проверяет, что Orange делится на 8 долек. И все! Не грейпфрут, не лимон — потому что их еще нет в системе.
Когда кто-то допишет систему до работы с Кокосами он допишет и тесты для проверки что кокос не делится на дольки (если это важно). А ваш тест, будет продолжать проверять чтобы Orange продолжал делиться на 8 долек. Никаких абстракций в тестах. Все должно быть конкретным.
— Что значит «лишнее выполнение теста»? Нет такого понятия! Тесты нужно выполнять _всегда_.
— Про дублирование зря беспокоитесь. Каждый тест должен проверять один аспект системы. Поэтому когда вы хотите проверить «округлость» апельсина — проверяйте только его «округлость», а не цвет, дольки и другую фигню. Не нужно ничего дублировать в начале каждого теста (но можно «поднимать» окружение в setUp() и tearDown()). Если вы перед проверкой на округлость станете проверять цвет, запах, и что-то еще, это станет проблемой. Тест на округлость станет падать от того, что апельсины черные, несмотря на то, что они круглые.
— «Шум от тестов» возникает гораздо реже, если каждый тест проверяет только один аспект (см. мои пояснения выше). Очень редко бывает так, чтобы слишком много аспектов системы вдруг начали сбоить (конечно если вы не заняты портированием сишного кода с одной архитектуры на другую). Но если все же такое случилось, и разом упали десятки или сотни тестов — приступайте к анализу того теста, который вы знаете лучше всего (из числа упавших, конечно). В этом случае вы просто увидите проблему. (Ах, триггеры не прописали! Ой, нет прав на запись в папку! Блин, либы не подложили."
3. Категорически не согласен. Ни один «человеческий» язык не достаточно формален, чтобы отражать конкретные детали. Сравните:
Видите? Проверка «округлости» может оказаться сравнением с заданным значением или вычислением меры «округлости».
4. «далее вводите матчеры»? Зачем? Чтобы запутать тех, кто попытается понять что делает ваш тест? И в дальнейшем, если тест упал, и нужно править матчер — это будет означать, что ваши исправления начнут влиять на все остальные тесты использующие этот матчер. Даже если они и не падали.
5.
6. Правильный матчер, слишком абстрактный чтобы написать например «У продавца в договоре должен быть записан телефон». Все сообщения которые можно сформировать на таком уровне абстракции уже и так формируются в методах assertEquals().
1. Первый пункт полностью голословный. Я сомневаюсь, что можно найти объективную количественную оценку, чтобы сказать, сказать что assertThat лучше чем assertEquals.
2. «Что делать, если потребуется… если неизвестно будет ли...» — это выражения НЕ для тестов. В тестах проверяются только 100% известные и конкретные факты.
Добавляете в систему Orange, и считаете что он должен делиться на дольки — пишете тест, который проверяет, что Orange делится на 8 долек. И все! Не грейпфрут, не лимон — потому что их еще нет в системе.
Когда кто-то допишет систему до работы с Кокосами он допишет и тесты для проверки что кокос не делится на дольки (если это важно). А ваш тест, будет продолжать проверять чтобы Orange продолжал делиться на 8 долек. Никаких абстракций в тестах. Все должно быть конкретным.
— Что значит «лишнее выполнение теста»? Нет такого понятия! Тесты нужно выполнять _всегда_.
— Про дублирование зря беспокоитесь. Каждый тест должен проверять один аспект системы. Поэтому когда вы хотите проверить «округлость» апельсина — проверяйте только его «округлость», а не цвет, дольки и другую фигню. Не нужно ничего дублировать в начале каждого теста (но можно «поднимать» окружение в setUp() и tearDown()). Если вы перед проверкой на округлость станете проверять цвет, запах, и что-то еще, это станет проблемой. Тест на округлость станет падать от того, что апельсины черные, несмотря на то, что они круглые.
— «Шум от тестов» возникает гораздо реже, если каждый тест проверяет только один аспект (см. мои пояснения выше). Очень редко бывает так, чтобы слишком много аспектов системы вдруг начали сбоить (конечно если вы не заняты портированием сишного кода с одной архитектуры на другую). Но если все же такое случилось, и разом упали десятки или сотни тестов — приступайте к анализу того теста, который вы знаете лучше всего (из числа упавших, конечно). В этом случае вы просто увидите проблему. (Ах, триггеры не прописали! Ой, нет прав на запись в папку! Блин, либы не подложили."
3. Категорически не согласен. Ни один «человеческий» язык не достаточно формален, чтобы отражать конкретные детали. Сравните:
// a) Человеческий язык
checkThatOrangeIsRounded()
// b) Первый формальный вариант
assertEquals(Shape.ROUND, fruit.getShape());
// c) Второй формальный вариант
float minimumDiameter = shtangentcirkul.getMinimalDiameter(fruit);
float maximumDiameter = shtangentcirkul.getMaximumDiameter(fruit);
assertTrue(minimumDiameter / maximumDiameter > 0.95);
Видите? Проверка «округлости» может оказаться сравнением с заданным значением или вычислением меры «округлости».
4. «далее вводите матчеры»? Зачем? Чтобы запутать тех, кто попытается понять что делает ваш тест? И в дальнейшем, если тест упал, и нужно править матчер — это будет означать, что ваши исправления начнут влиять на все остальные тесты использующие этот матчер. Даже если они и не падали.
5.
assertThat(fruits, everyItem(hasShape(Shape.ROUND))); не упадет, если список окажется пустым, а assertEquals(Shape.ROUND, fruit.get(0)) упадет.6. Правильный матчер, слишком абстрактный чтобы написать например «У продавца в договоре должен быть записан телефон». Все сообщения которые можно сформировать на таком уровне абстракции уже и так формируются в методах assertEquals().
1. Такая оценка есть — легкость замены проверки и количество строк кода, которые нужно редактировать при изменении требований. Предположим, стало необходимым проверять что поля не эквивалентны, а одно должно содержать другое в своем значении. С assertEquals придется переписывать тест с 0. Как и все тесты, где используется поле, к которому изменились критерии оценки. А если еще и комментарий составлялся вручную, так и с ним придется тоже заморочиться. С матчером — либо просто подредактировать один класс текущего матчера, либо просто заменить матчер на другой.
2. Тесты призваны находить ошибки. В случае если вы в полной уверенности что создали апельсин, а вместо него создалось яблоко (например если вы тестируете фабрику фруктов), вам будет достаточно диагностики от 2х проваленных тестов, вам не нужен уже запуск остальных, которые зависят от этих свойств.
Другой пример — предположим, вы запрограммировали два объекта и операцию разности между ними. Вы тестируете в одном тесте, что если их получать одинаковым способом, то они будут эквивалентны. В другом тесте вам нужно проверить, что если один вычесть из другого, то они дадут null (или что то определенное известное). Если у вас сломался механизм получения одинаковых объектов, то вам совершенно не нужно отвлекаться на то, что разность двух таких объектов не равна ожидаемому значению. Вам нужно игнорировать все тесты, которые зависят от механизма получения одинаковых объектов, но не проверяют его напрямую. Это шум, который может быть значительным.
«Тест на округлость станет падать от того, что апельсины черные, несмотря на то, что они круглые.» — Ситуации когда логика говорит — все круглое должно быть оранжевым, но при этом все апельсины должны быть круглыми, а их цвет не важен. Как такое организовать только на assertEquals? Это возможно, но зачем пытаться извратиться, когда это легко помогают решить матчеры, вынеся логику в один отдельный объект и позволяя вращать и объединять эту логику как нравится и в любых количествах.
2. Тесты призваны находить ошибки. В случае если вы в полной уверенности что создали апельсин, а вместо него создалось яблоко (например если вы тестируете фабрику фруктов), вам будет достаточно диагностики от 2х проваленных тестов, вам не нужен уже запуск остальных, которые зависят от этих свойств.
Другой пример — предположим, вы запрограммировали два объекта и операцию разности между ними. Вы тестируете в одном тесте, что если их получать одинаковым способом, то они будут эквивалентны. В другом тесте вам нужно проверить, что если один вычесть из другого, то они дадут null (или что то определенное известное). Если у вас сломался механизм получения одинаковых объектов, то вам совершенно не нужно отвлекаться на то, что разность двух таких объектов не равна ожидаемому значению. Вам нужно игнорировать все тесты, которые зависят от механизма получения одинаковых объектов, но не проверяют его напрямую. Это шум, который может быть значительным.
«Тест на округлость станет падать от того, что апельсины черные, несмотря на то, что они круглые.» — Ситуации когда логика говорит — все круглое должно быть оранжевым, но при этом все апельсины должны быть круглыми, а их цвет не важен. Как такое организовать только на assertEquals? Это возможно, но зачем пытаться извратиться, когда это легко помогают решить матчеры, вынеся логику в один отдельный объект и позволяя вращать и объединять эту логику как нравится и в любых количествах.
3.
4. Грамотно написанный матчер говорит все что делает своим названием, содержит четкую логику в одном определенном месте и никак не может запутать — матчер тоже не должен быть аля «проверить что все круто». Соответственно если меняется логика всей проверки матчера, то невозможна ситуация, когда в одном месте она должна быть старой, а в другом — новой. Тут либо изначально должно быть несколько матчеров, либо где то закралась ошибка в тесты.
5. Если список не должен быть пустым, то матчер должен выглядеть так:
Это будет ошибкой формулировки требования к проверке, а не ошибкой матчера.
6.
Надо проверить что телефон подходит под паттерн? Меняем только внутренний матчер:
Реализацию несложно придумать на основе того же
Кстати учитывайте, что тесты на JUnit могут быть не только юнит-тестами, но и функциональными и интеграционными. В этом случае мы не владеем кодом, который тестируем и не можем его разобрать на объектики и довольствуемся только внешними интерфейсами.
// c) Второй формальный вариант
float minimumDiameter = shtangentcirkul.getMinimalDiameter(fruit);
float maximumDiameter = shtangentcirkul.getMaximumDiameter(fruit);
assertTrue(minimumDiameter / maximumDiameter > 0.95);
//С матчером самописным - чем не формально и при этом человекочитаемо?
assertThat(fruit, hasDiameterMinToMaxDivision(greaterThan(0.95)));
public static Matcher<Fruit> hasDiameterMinToMaxDivision(Matcher<Double> matcher) {
return new FeatureMatcher<Fruit, Double>(matcher, "exp", "was") {
@Override
protected Double featureValueOf(Fruit actual) {
Double minimumDiameter = shtangentcirkul.getMinimalDiameter(fruit);
Double maximumDiameter = shtangentcirkul.getMaximumDiameter(fruit);
return minimumDiameter / maximumDiameter;
}
};
}
// Со стандартными матчерами hamcrest - greaterThan равноценно > - но читается проще. + Без лишних телодвижений заодно расскажет что ждали и что получили.
assertThat(minimumDiameter / maximumDiameter, greaterThan(0.95))
4. Грамотно написанный матчер говорит все что делает своим названием, содержит четкую логику в одном определенном месте и никак не может запутать — матчер тоже не должен быть аля «проверить что все круто». Соответственно если меняется логика всей проверки матчера, то невозможна ситуация, когда в одном месте она должна быть старой, а в другом — новой. Тут либо изначально должно быть несколько матчеров, либо где то закралась ошибка в тесты.
5. Если список не должен быть пустым, то матчер должен выглядеть так:
assertThat(fruits, both(hasSize(greaterThan(0))).and(everyItem(hasShape(Shape.ROUND))));
Это будет ошибкой формулировки требования к проверке, а не ошибкой матчера.
6.
assertThat(seller, hasDocument(withTelephone(not(nullValue()))));
Надо проверить что телефон подходит под паттерн? Меняем только внутренний матчер:
assertThat(seller, hasDocument(withTelephone(matchesPattern("\+7[0-9]{10}"))));
Реализацию несложно придумать на основе того же
FeatureMatcherКстати учитывайте, что тесты на JUnit могут быть не только юнит-тестами, но и функциональными и интеграционными. В этом случае мы не владеем кодом, который тестируем и не можем его разобрать на объектики и довольствуемся только внешними интерфейсами.
1. Если требования меняются — тесты должны меняться! Если при изменении требований тесты не меняются (но меняется матчеры), то значит ваши тесты не отражают требования к системе. То есть они перестают быть юнит-тестами. Переименуйте их в SistemValidationMatcherInvocator, чтобы я не путал их с юнит-тестами, и продолжим.
2. Вы снова преподносите какую-то гипотетическую возможность предсказать падение тестов и отказаться от их запуска. Зачем?
Я расскажу как я пишу код с тестами (думаю многие так делают):
— В IDEA я запускаю один класс с тестами, для той части с которой я работаю. Бывает, что даже запускаю всего один тест (из контекстного меню).
— Вношу исправления в код, в тесты, раз за разом запуская один этот тест, пока он не заработает.
— Запускаю Весь тестовый класс для той части, которую только что правил, и если все тесты для этой подсистемы прошли
— Запускаю все имеющиеся тесты
Ваш «другой пример» отпадает при моем подходе. Пока я ковыряю механизм получения одинаковых объектов, и тест на проверку этого механизма падает, я смотрю только на этот тест. Шуму неоткуда взяться.
«Все круглое оранжевое, а апельсины круглые, но неважно какого цвета» — это снова слишком абстрактные утверждения, мало полезные для модульных тестов. В тестах необходимо проверить каждый конкретный фрукт.
3. Вот тут вам удалось привести достойный пример:
Этот код достаточно прямолинейный, конкретный и наглядный.
4. Чтобы преодолеть сложность написания «Грамотно написанного юнит-теста» вы предлагаете написать «Грамотно написанный матчер»?
5. Акцентирую внимание, что
Этот фрагмент точно также скрывает особенность своего ложно-отрицательного срабатывания в случае пустого списка. Выглядит как будто есть проверка, а на самом деле, в некоторых случаях ее нет! Поэтому я рекомендую стараться писать как можно более простые тесты, и «даже списки индексировать константами». Потому что фрагмент:
и выглядит как проверка, и является проверкой.
6. Предложенный вами вариант нельзя точно прочесть не открывая матчер. Он может быть
Согласен, что связка Mockito + Hamcrest + JUnit может сделать с «закрытой» системой гораздо больше, чем доступ через открытые интерфейсы. Однако, как ни печально, эта особенность является НЕДОСТАТКОМ для системы модульного тестирования (в случае Test Driven Design). Такие тесты не заставят вас проектировать более удобные интерфейсы между компонентами вашей системы.
2. Вы снова преподносите какую-то гипотетическую возможность предсказать падение тестов и отказаться от их запуска. Зачем?
Я расскажу как я пишу код с тестами (думаю многие так делают):
— В IDEA я запускаю один класс с тестами, для той части с которой я работаю. Бывает, что даже запускаю всего один тест (из контекстного меню).
— Вношу исправления в код, в тесты, раз за разом запуская один этот тест, пока он не заработает.
— Запускаю Весь тестовый класс для той части, которую только что правил, и если все тесты для этой подсистемы прошли
— Запускаю все имеющиеся тесты
Ваш «другой пример» отпадает при моем подходе. Пока я ковыряю механизм получения одинаковых объектов, и тест на проверку этого механизма падает, я смотрю только на этот тест. Шуму неоткуда взяться.
«Все круглое оранжевое, а апельсины круглые, но неважно какого цвета» — это снова слишком абстрактные утверждения, мало полезные для модульных тестов. В тестах необходимо проверить каждый конкретный фрукт.
3. Вот тут вам удалось привести достойный пример:
assertThat(minimumDiameter / maximumDiameter, greaterThan(0.95))
Этот код достаточно прямолинейный, конкретный и наглядный.
4. Чтобы преодолеть сложность написания «Грамотно написанного юнит-теста» вы предлагаете написать «Грамотно написанный матчер»?
5. Акцентирую внимание, что
assertThat(fruits, everyItem(hasShape(Shape.ROUND))) — вполне корректный фрагмент. Но он плохо подходит под требование «простоты» и «прямолинейности» тестовых методов. Также как цикл:for(Fruit fruit : fruits) {
assertEquals(Shape.ROUND, fruit.getShape());
}
Этот фрагмент точно также скрывает особенность своего ложно-отрицательного срабатывания в случае пустого списка. Выглядит как будто есть проверка, а на самом деле, в некоторых случаях ее нет! Поэтому я рекомендую стараться писать как можно более простые тесты, и «даже списки индексировать константами». Потому что фрагмент:
assertEquals(Shape.ROUND, fruits.get(0).getShape())
и выглядит как проверка, и является проверкой.
6. Предложенный вами вариант нельзя точно прочесть не открывая матчер. Он может быть
// 1
assertEquals("+7923xxxxxxx", seller.getPhone());
// 2
assertEquals("+7923xxxxxxx", document.getSellerPhone());
// 3
assertEquals(seller.getPhone(), document.getSellerPhone());
Согласен, что связка Mockito + Hamcrest + JUnit может сделать с «закрытой» системой гораздо больше, чем доступ через открытые интерфейсы. Однако, как ни печально, эта особенность является НЕДОСТАТКОМ для системы модульного тестирования (в случае Test Driven Design). Такие тесты не заставят вас проектировать более удобные интерфейсы между компонентами вашей системы.
Если при изменении требований тесты не меняются (но меняется матчеры), то значит ваши тесты не отражают требования к системе. То есть они перестают быть юнит-тестами.
Матчеры — это что. Тесты — это как. Это одно целое, разделенное во взаимосвязанные сущности. Код матчера можно обычно копипастить внутрь теста, и ничего от этого не изменится. Но когда такая проверка занимает больше того, что можно воспринять за пару секунд внутри теста, либо когда такая проверка встречается несколько раз — ее выносят для переиспользования и логического отделения. Изменение этого кода ничем не отличается от изменения теста.
2. Хорошо. Когда есть возможность ковырять один объект и локально же запускать для него тестики — в этом случае шум действительно не проблема. Но этот подход не работает для набора функциональных и интеграционных тестов, которые нужно запускать все разом и диагностировать точно первопричину, а не тот факт что все сломалось и паника паника паника. Особенно когда тесты запускаются автоматом после выкладки нового кода, а об их провале идут уведомления в смс, почту и куда то еще.
4. Матчер — еще более атомарная единица (сорри за тавтологию), чем тест — поэтому его чистоту отследить проще.
5. Мок объекты скрывают свою подлую пустую сущность, давайте не будем их использовать?
Характеристика линейности вполне осязаема — отсутствие ветвления — цикл — ветвление, условие — ветвление. Вызов инструмента, работающего по четкой спецификации — это не странные пассы руками, это его применение по назначению. Перебор элементов вручную ничем от такого вызова не отличается, кроме огромного количества лишней работы. По поводу пустоты списка повторюсь — нужно четко формулировать что нужно проверить.
6. seller что? hasDocument. Значит у продавца есть документ, ок. Документ какой? withTelephone. Телефон должен быть каким? Не пустым — withTelephone(not(nullValue()))
«У продавца в договоре должен быть записан телефон»
О том сколько вариантов проверок можно еще нагенерировать из этой фразы — это проблемы фразы, русский язык вполне позволяет указать более точные формулировки, и так же точно матчеры позволяют уточнять детали.
Проблема того что нужно заглянуть в реализацию матчера — не проблема, это же не структурное программирование.
1. Если вследствие изменения функционального требования меняется тест, то можно сказать, что он отражает это требование. Если же тест не меняется, то НЕ отражает. Юнит-тесты _должны_ отражать требования. Следовательно, то, что не отражает функциональные требования не может называться юнит тестом.
Если же делать по одному матчеру на каждый тест, и туда выносить логику проверки, то придет Оккам и бритвой попишет!
2.
Да, я говорил о юнит тестах. Потому как для всех остальных видов автоматического тестирования проблема шума вообще не может возникнуть.
А вот в этом случае как раз необходимо, чтобы система тестирования выполнила каждый тест. Так как на результаты будут смотреть все разработчики, и каждый полезет проверять свою часть работы.
3. ~
4. Вы думаете проще отследить «чистоту» матчера который должен меняться вслед за изменением функциональных требований и архитектуры проверяемой системы? Или вы надеетесь, что матчер будет настолько обобщенным, что ему не придется меняться вслед за изменением требований и архитектуры?
5.
6. Мое тестовое описание функциональности — слишком неконкретное, и может означать очень много чего. То же самое и предлагаемый вами код — такой же неформальный. А для понимания теста нужны конкретные детали — те три приведенные мной примера подходят и под ваш код, и под мое словесное описание, но ожидают различных реакций от системы.
Если же делать по одному матчеру на каждый тест, и туда выносить логику проверки, то придет Оккам и бритвой попишет!
2.
Но этот подход не работает для набора функциональных и интеграционных тестов
Да, я говорил о юнит тестах. Потому как для всех остальных видов автоматического тестирования проблема шума вообще не может возникнуть.
Особенно когда тесты запускаются автоматом после выкладки нового кода
А вот в этом случае как раз необходимо, чтобы система тестирования выполнила каждый тест. Так как на результаты будут смотреть все разработчики, и каждый полезет проверять свою часть работы.
3. ~
4. Вы думаете проще отследить «чистоту» матчера который должен меняться вслед за изменением функциональных требований и архитектуры проверяемой системы? Или вы надеетесь, что матчер будет настолько обобщенным, что ему не придется меняться вслед за изменением требований и архитектуры?
5.
четко формулировать что нужно проверить. Вот мы и вернулись, к требованию «простоты» и «прямолинейности» тестов. А самый прямолинейный подход — проверять списки явно. Насчет лишней работы не беспокойтесь — Ctrl+D — легко и непринужденно дублирует строки.6. Мое тестовое описание функциональности — слишком неконкретное, и может означать очень много чего. То же самое и предлагаемый вами код — такой же неформальный. А для понимания теста нужны конкретные детали — те три приведенные мной примера подходят и под ваш код, и под мое словесное описание, но ожидают различных реакций от системы.
Программирование путём построения примитивов, объединяющихся друг с другом комбинаторами в произвольные формы является одним из моих излюбленных приёмов с тех пор, как я увидел такой подход в SICP. Комбинаторы парсеров, функторы, futures и прочие монады — это прекрасно.
Какую задачу пытались решить?
Конечно assertTrue может потребовать сообщения:
Но можно написать так:
Я в недоумении.
assertEquals(Shape.ROUND, fruit.getShape()) — вот эта строчка сформирует суперское сообщение об ошибке и кристально ясный стэк трейс.assertThat(someFruit, is(round())) — выдаст запутанный стэк трейс.Конечно assertTrue может потребовать сообщения:
assertTrue("The fruit was not sweet as it MUST be.", fruit.isSweat())Но можно написать так:
assertEquals(true, fruit.isSweat()), и сообщение станет "expected:<true> but was:<false>" — на практике такого сообщения обычно достаточно.Я в недоумении.
Сравним на примере (можно позапускать тесты из примеров к статье на гитхабе)
используя assertEquals:
Используя матчер:
Вам не понравились строчки стектрейса, которые относятся к
Но их любая IDE даже подсвечивает другим цветом.
А что делать, если нам нужно игнорировать все тесты, которые не удовлетворяют условию? В случае с матчером, нам стоит просто поменять assertThat на assumeThat — с assertTrue такое прокатит, но там нужно везде думать о сообщении. А вот с assertEquals не сработает
используя assertEquals:
junit.framework.AssertionFailedError: Expected shape - ROUND, but was - SQUARE expected:<SQUARE> but was:<ROUND>
at ru.yandex.qatools.examples.FruitDegustationTest.orangeIsRoundWithAssert(FruitDegustationTest.java:54)
Используя матчер:
java.lang.AssertionError:
Expected: fruit has shape - <ROUND>
but: shape - was <SQUARE>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at ru.yandex.qatools.examples.FruitDegustationTest.orangeIsRoundWithMatcher(FruitDegustationTest.java:61)
Вам не понравились строчки стектрейса, которые относятся к
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
Но их любая IDE даже подсвечивает другим цветом.
А что делать, если нам нужно игнорировать все тесты, которые не удовлетворяют условию? В случае с матчером, нам стоит просто поменять assertThat на assumeThat — с assertTrue такое прокатит, но там нужно везде думать о сообщении. А вот с assertEquals не сработает
У меня такое ощущение, что мы разговариваем о разных тестах. Что значит «игнорировать все тесты, которые не удовлетворяют условию»?
Если есть модульный тест — запускай его! Если нет — напиши! Вот и всё.
Может быть вы пытаетесь написать модульный тест, способный работать при любом состоянии испытуемой системы? Этого не требуется. Мало того, модульный тест должен падать, если система не в том состоянии, на которое он рассчитывал.
Если есть модульный тест — запускай его! Если нет — напиши! Вот и всё.
Может быть вы пытаетесь написать модульный тест, способный работать при любом состоянии испытуемой системы? Этого не требуется. Мало того, модульный тест должен падать, если система не в том состоянии, на которое он рассчитывал.
Да, возможно в разных видах тестов есть мелкие нюансы, которые могут влиять на детали применения инструментов. Но общая идеология неизменна — Должен быть тест на проверку состояния системы, который один и должен упасть. Остальные тесты ожидаемо упадут в этом случае. Зачем нагружать разработчика поиском и сортировкой упавших тестов, чтобы выявить первопричину, если это можно сделать программно при помощи стандартных средств JUnit+Hamcrest? И сэкономить в последующем во много раз больше времени, чем вставка лишнего assume и комбинации матчеров
JUnit + Hamcrest не помогут выявить первопричину при «обильном» падении тестов, а вот скрыть эту причину они очень даже могут. Например вы только что написали тест, и отлично его помните. Система как-то очень сильно сломалась, но ваш тест даже не запустился (как и множество других). И вам во-первых не видно, что произошел обильный обвал тестов, а во-вторых в качестве причины указывается малознакомый или вообще незнакомый аспект. Вы писали фабрику фруктов, а упал какой-нибудь «Can not bind AccessRughts to null».
Обильные падения тестов не проблема — если все тесты упали — это красиво!
А вот если ваши тесты показывают что сломалась какая-нибудь левая фигня, вместо того, чтобы показать, что сломалась вся фигня целиком, вот это проблема.
Бывают «Хрупкие системы» — системы с чрезмерным внутренним связыванием. При малейшем изменении начинают валиться как карточный домик. Для таких систем особенно полезно проверять по одному аспекту в одном тесте.
Обильные падения тестов не проблема — если все тесты упали — это красиво!
А вот если ваши тесты показывают что сломалась какая-нибудь левая фигня, вместо того, чтобы показать, что сломалась вся фигня целиком, вот это проблема.
Бывают «Хрупкие системы» — системы с чрезмерным внутренним связыванием. При малейшем изменении начинают валиться как карточный домик. Для таких систем особенно полезно проверять по одному аспекту в одном тесте.
Пожалуй, после
дальнейший спор на эту тему с вами перерастет исключительно в холивар, так как это прямой переход от теплого к мягкому в обсуждении фактов.
если все тесты упали — это красиво!
дальнейший спор на эту тему с вами перерастет исключительно в холивар, так как это прямой переход от теплого к мягкому в обсуждении фактов.
А как насчет процитировать вторую мою фразу?
В этой части наши взгляды совпадают?
А вот если ваши тесты показывают что сломалась какая-нибудь левая фигня, вместо того, чтобы показать, что сломалась вся фигня целиком, вот это проблема
В этой части наши взгляды совпадают?
Вы знаете как работает assume?
Специально почитал. «The default JUnit runner treats tests with failing assumptions as ignored». Да, я верно представляю себе как работает assume.
Но все равно считаю, что падение всех тестов, лучше чем закулисный отказ от исполнения хотя бы одного теста. Вы согласны с этим?
Но все равно считаю, что падение всех тестов, лучше чем закулисный отказ от исполнения хотя бы одного теста. Вы согласны с этим?
Нет, я не могу понять чем сможет помочь в диагностике заведомо сломанный тест, упавший с НПЕ, ошибкой подключения к бд итд. Тест при прохождении assume выполнится — просто его непрохождение на шаге assume избавит от ложных ошибок.
Предположим у вас есть 7000 единичных аспектов функционирования системы. И на каждый из них есть по одному тесту. Но в тестах используются assume, которые в некоторых условиях «отключают» некоторые тесты. Таким образом у вас 6800 тестов «проходят», остальные игнорируются по assume. Проходят они или нет, вам не видно — они игнорируются.
Что делать в таком случае?
* Включить «дурака», сказать «у нас все тесты проходят», и отдать такую систему в QA
* Считать, что игнорируемые тесты все равно что упавшие, и заняться поиском причин
Выбирайте.
Что делать в таком случае?
* Включить «дурака», сказать «у нас все тесты проходят», и отдать такую систему в QA
* Считать, что игнорируемые тесты все равно что упавшие, и заняться поиском причин
Выбирайте.
Таким образом у вас 6800 тестов «проходят», остальные игнорируются по assume. Проходят они или нет, вам не видно — они игнорируются.
Не могут часть пройти — часть игнорироваться. Должен быть тест на проверку условия игнорирования. Он должен зафейлиться. Соответственно будет 6799 тестов прошедших, 1 проваленный, сообщающий точную ошибку и 200 проигнорированных по той же самой причине. Как итог — смотрим не на 200 одинаково упавших тестов, а на 1.
Конечно, в этом случае должна быть установка, что любой проваленный тест это блокер к выкладке.
Ах, да. Ненаучная фантастика. Слышал об этом.
Я, возможно, смог бы добиться такой согласованности тестов, на «замороженной» системе. Но в реальных условиях, при непрерывном изменении функциональности системы, это даже мне не под силу.
Кроме того, зависимость юнит-тестов друг от друга — источник проблем.
Даже в вашем примере, в случае какой-нибудь ошибки в тесте который должен был бы упасть у вас будет 6799 прошедших, 201 игнорируемых, и ни малейших намеков на источник проблемы.
Я, возможно, смог бы добиться такой согласованности тестов, на «замороженной» системе. Но в реальных условиях, при непрерывном изменении функциональности системы, это даже мне не под силу.
Кроме того, зависимость юнит-тестов друг от друга — источник проблем.
Даже в вашем примере, в случае какой-нибудь ошибки в тесте который должен был бы упасть у вас будет 6799 прошедших, 201 игнорируемых, и ни малейших намеков на источник проблемы.
У игнорируемых тестов аналогично упавшим пишется причина игнора. При желании ее всегда можно увидеть.
Мне непонятно еще как возможно, что одна и та же проверка в одном случае пройдет, а в другом — не пройдет. Что это за юнит тесты такие, которые так колбасит?
Мне непонятно еще как возможно, что одна и та же проверка в одном случае пройдет, а в другом — не пройдет. Что это за юнит тесты такие, которые так колбасит?
У игнорируемых тестов аналогично упавшим пишется причина игнора
то есть вы выбираете второй пукт:
Считать, что игнорируемые тесты все равно что упавшие, и заняться поиском причин
Хорошо. Я бы в такой ситуации тоже выбрал бы этот пункт.
Мне непонятно еще как возможно, что одна и та же проверка в одном случае пройдет, а в другом — не пройдет
Юнит-тест должен падать, если:
1. В результате разработки были внесены непреднамеренные изменения функционирования
2. Если система оказалась в такой среде, где ее корректное функционирование нарушилось
3. Если система изменилась вслед за изменением требований, а тесты еще не отражают это изменение.
Так упадет же тест один. Чем помогут еще 200 упавших с той же самой ошибкой? Они просто программно пометятся проскипанными. Зачем заставлять разработчика самостоятельно глазами смотреть на одинаково упавшие тесты и для себя их помечать проигнорированными? Я не пойму, в чем понт делать ту работу, которую можно автоматизировать?
1. Упавший тест == Некорректный работа одного аспекта.
Проскипанный тест == неизвестность
2. Проблемы «шума» НЕ существует:
Для разработчика нет проблемы шума, т.к. он обычно запускает один и тот же тест, пока не завершит свою часть.
Для инженера интеграции (если такой есть), этой проблемы тоже не существует, т.к. от него ждут что он прогонит каждый тест и отловит ситуации с неправильной конфигурацией.
Для тестирования перед передачей в QA также не существует проблемы шума, т.к. результаты будут смотреть все разработчики.
Кроме того, ситуации когда падает значительное число тестов обычно весьма тривиальные — нарушение конфигурирования. Зачем пытаться защититься от этой ситуации, когда любой junior сможет с ней разобраться?
3. Эту работу нельзя автоматизировать.
Юнит-тесты это бурлящий котел. Они постоянно добавляются, удаляются и изменяются. Добиться того, чтобы всегда падал ровно один тест, а остальные предсказанно-падучие игнорировались, неподъемная задача. Даже если в какой-то момент вы добьетесь положительного результата, кто-то допишет новый тест, в котором забудет assume и вот у вас уже два упавших теста, и куча проскипаных.
Нам стоит вернуться в началу.
Какую задачу нужно решить?
Проскипанный тест == неизвестность
2. Проблемы «шума» НЕ существует:
Для разработчика нет проблемы шума, т.к. он обычно запускает один и тот же тест, пока не завершит свою часть.
Для инженера интеграции (если такой есть), этой проблемы тоже не существует, т.к. от него ждут что он прогонит каждый тест и отловит ситуации с неправильной конфигурацией.
Для тестирования перед передачей в QA также не существует проблемы шума, т.к. результаты будут смотреть все разработчики.
Кроме того, ситуации когда падает значительное число тестов обычно весьма тривиальные — нарушение конфигурирования. Зачем пытаться защититься от этой ситуации, когда любой junior сможет с ней разобраться?
3. Эту работу нельзя автоматизировать.
Юнит-тесты это бурлящий котел. Они постоянно добавляются, удаляются и изменяются. Добиться того, чтобы всегда падал ровно один тест, а остальные предсказанно-падучие игнорировались, неподъемная задача. Даже если в какой-то момент вы добьетесь положительного результата, кто-то допишет новый тест, в котором забудет assume и вот у вас уже два упавших теста, и куча проскипаных.
Нам стоит вернуться в началу.
Какую задачу нужно решить?
Окей, давайте остановимся на том, что в юнит тестировании это дело выбора каждого, тут матчеры могут здорово упростить жизнь во многих ситуациях, а могут просто не понадобиться. Тем кто не пробовал, стоит попробовать — ничего страшного в них нет, писать их недолго, поддерживать — не сложнее тестов. Во многих случаях они могут просто сыграть роль синтаксического сахара. Многие живут без матчеров и рады. Есть те, которые пишут почти стихи при помощи матчеров, но при этом проверки формальные и строгие.
В функциональном тестировании, где продукт творчества программистов остается черным ящиком, матчеры — вырезающие из тестов тонны дубликатов в удобоваримые проверки с кучей плюшек — это качественный рывок вверх для тестов во всех отношениях и тут их нужно использовать без альтернатив.
В любом случае, все assertEquals(1, 2) стоит заменить на assertThat(2, equalTo(1)). Потому как вывод ошибки одинаков, но в случае изменения требований к тесту заменить equalTo() на greaterThanOrEqualTo() или lessThan() будет гораздо дешевле, чем переписывать логику получения значения из 2 и приводить к нужному виду в соответствие с 1. Это тоже считается использованием матчеров
В функциональном тестировании, где продукт творчества программистов остается черным ящиком, матчеры — вырезающие из тестов тонны дубликатов в удобоваримые проверки с кучей плюшек — это качественный рывок вверх для тестов во всех отношениях и тут их нужно использовать без альтернатив.
В любом случае, все assertEquals(1, 2) стоит заменить на assertThat(2, equalTo(1)). Потому как вывод ошибки одинаков, но в случае изменения требований к тесту заменить equalTo() на greaterThanOrEqualTo() или lessThan() будет гораздо дешевле, чем переписывать логику получения значения из 2 и приводить к нужному виду в соответствие с 1. Это тоже считается использованием матчеров
Хотелось бы надеяться что матчеры принесут больше выгоды чем проблем.
Я внимательно к ним присматриваюсь, т.к. часто код с матчерами оказывается компактнее чем plain java. Но пока, мне кажется, что недостатки перевешивают достоинства.
Недостатки:
* Код с матчерами теряет «прозрачность»
* Утверждения относящиеся к функциональности перетекают из кода тестов в матчеры
* Увеличивается взаимное влияние тестов друг на друга через матчеры
* Матчеры не стимулируют разработку удобных интерфейсов между подсистемами
Из достоинств только то, что код, использующий матчеры, выглядит компактнее.
Я внимательно к ним присматриваюсь, т.к. часто код с матчерами оказывается компактнее чем plain java. Но пока, мне кажется, что недостатки перевешивают достоинства.
Недостатки:
* Код с матчерами теряет «прозрачность»
* Утверждения относящиеся к функциональности перетекают из кода тестов в матчеры
* Увеличивается взаимное влияние тестов друг на друга через матчеры
* Матчеры не стимулируют разработку удобных интерфейсов между подсистемами
Из достоинств только то, что код, использующий матчеры, выглядит компактнее.
Вот сслыка на мой комент
habrahabr.ru/post/174781/#comment_6073323
Там критикуется код с матчером. Выглядит компактно, зато полный набор недостатков.
habrahabr.ru/post/174781/#comment_6073323
Там критикуется код с матчером. Выглядит компактно, зато полный набор недостатков.
Интересно кто-нибудь исследовал «антипаттерны» использования Hamcrest в модульном тестировании?
Sign up to leave a comment.
Тестирование в Яндексе. Матчеры: когда они полезны и как легко их использовать