Заблуждения об автоматическом тестировании

[lair]

Эм, аргументы, которые сводятся к "используйте правильный фреймворк для кода и тестов" — это не очень.

[lair]

В любом случае тестирование должно осуществляться "правильным" движком, которому не важно что за код вы ему скармливаете.

А теперь — критерии правильного движка в студию. Может, правда, выясниться, что движки для юнит-тестов и поведенческих тестов немножко разные, но что уж тут...

[Danik-ik]

Мне почему-то кажется, что "Неважно, какой код скармливаете" бывает только в случае "код не имеет смысла".

"Отвесьте мне кода на три тыщи рупий, пжалста. Неважно, какого, мне для тестирования"...

[VolCh]

Если под компонентом имеется в виду часть кода, обладающая как своим внутренним состоянием и логикой его изменения, так и своим UI, то есть по сути являющаяся мини-приложением, то и тесты к ней надо писать исходя из принципов тестирования приложения, а не отдельных его модулей, приемочные/функциональные тесты, а не юнит/интеграционные. И инструментарий соответствующий, эмулирующий действия пользователя, а не программных клиентов API.

Что не исключает, конечно, что можно тестировать модульными тестами поведение изолированных частей компонента и их интеграцию интеграционными.

Given/when/then — это, прежде всего, про низкоуровневые тесты, в лучшем случае тесты одного действия пользователя, а не про тестирование сценариев.

[lxsmkv]

Я выравнял вам минус. Еще не хватало за вполне оправданные вопросы минусовать. Тут все таки не только доктора наук тусуются. Какие все таки токсичные люди… Ладно.

Имеются ввиду части кода использующие интерфейс. Самый для меня наглядный пример: мы пишем тесты на PageObjects. Каждый такой PageObject является контроллером для страницы. А тестовый сценарий — это процедура, состоящая из вызовов методов одного или нескольких таких PageObjects. Так вот, тестовая функция и будет клиентом предоставлямых этими контроллерами публичных методов. А публичные методы это и есть интерфейс. То что видно и доступно всем для использования. Набор публичных методов класса это его АPI. Надеюсь что-то прояснил?

[lxsmkv]

С Given/When/Then как мне кажется все в порядке. Check не нужен. Check это тот же Тhen.
Вы пытаетесь освободиться от парадигмы, а надо ее принять. Или вы в мире GWT или нет.
Так вот, если вы в мире GWT, то вместо этого

console.assert( Math.pow( 2, 3 ) === 8 ) // Then

должно получиться что-то такое (псевдокод):
/*Given*/ exponent = 3; base = 2;
/*When*/ result = Math.pow(base, exponent)
/Then */ assert_equals(result,8)
Этот сценарий обьясняет на примере как работает функция pow. И в этом его дополнительная ценность как документации, когда он представлен в виде GWT.

Да, как вы справедливо заметили, это выглядит немного неуклюже и избыточно. Но парадигма это всегда кандалы которые ты добровольно одеваешь себе на руки. Ты меняешь свое мировосприятие под парадигму, а не наоборот.

И, чтобы мир рассыпался в пыль окончательно — в тесте сделанном на чистом GWT не может быть условий. Каждая ветвь условия это отдельный тестовый сценарий.

Вообще надо сказать, что GWT проще ложится на приемочные сценарии, в которых эмулируется поведение пользователя.

[joemast]

Обычно аргументом против такого подхода выступает сложность понимания какой из ассертов упал

Нет, аргументом против этого выступает сложность понимания почему упал тест. Хороший тест падает по одной единственной причине, ради проверки которой он и создан.

[lxsmkv]

Если нет возможности использовать мягкие ассерты, а нужно заассертить несколько условий, например:

когда мы отжимаем в плеере кнопку «пауза» таймер проигрывателя начинает меняться, меняется иконка кнопки и еще что-нибудь

можно решить это через накопительный код ошибки. Первое условие единица, второй двойка, четверка, восьмерка. и.т.д В логе декодируешь ошибку и выводишь все, что пошло не так.