С какого-то возраста появился вопрос: «Зачем?».

Вот раньше ты встречал упоминание, например, о популярной технологии. И ты сразу начинал ее изучать. Если бы тебя спросили: «А зачем?», ты бы сказал: «Ну как зачем? Ты что, дурак? Новая для меня технология. Популярная. Пригодится ж наверняка. Изучу, опробую, ну!». А сейчас…

Тебе предлагают изучить, а ты думаешь: «Какая-то технология. Очередная. Сложность обучения у нее высокая. Это ж изучать ее надо, разбираться, пробовать. Я там далеко не первый буду, значит уже многие знают ее куда лучше меня, конкуренция. А потом что? То ли использовать, то ли забыть, а ведь еще работа есть. Ну и зачем?..»

Известным монологом навеяло. Эту проблему пока для себя не решил. А может, и не надо ее решать?

Аннотация

Статья рассказывает о нетрадиционном, но полезном виде тестов, а также подводит итоги семилетней работы в разработке тестов.

Зачем нужны компонентные тесты?

Ведь есть, скажем, юнит-тесты, которые подробно тестируют потроха компонентов. Они досконально проверяют, что компонент работает в соответствии с замыслом разработчика. Но часто это проверка "пуговиц", а не того, как сидит костюм в целом. И не всегда поведение, задуманное программистом, совпадает с тем что хотел заказчик.

А еще есть, например, приемочные тесты. И они устраняют все указанные недостатки. Но, к сожалению, вносят новые. Они медленные, часто нестабильные, и обычно ручные. При этом они только свидетельствуют о проблеме, но не локализуют ее.

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