Я надеюсь, что как грамотный разрабочик, вы имеете представление о unit-тестировании и сделаете себе в голове пару мысленных отметок о том, чего надо избегать при написании тестов. Знакомьтесь:

Лжец (The Liar)

Unit-тест, который успешно выполняет все кейсы и выглядит работающим правильно, однако при более детальном рассмотрении обнаруживается, что он на самом деле не тестирует то, что должен.

Непопулярные аспекты тестирования

     Каждый разработчик знает, что писать тесты это правильно, часть разработчиков знает это на своем опыте, другая из книг тех программистов, которые знают это на личном опыте и умеют продавать свои книги. Писать книги я не умею, да и опыта мало, но поделиться некоторыми аспектами использования unit тестов я могу. Ниже, я постараюсь поменьше упоминать прописные истины, но побольше оригинальных мыслей. Все размышления не привязаны к какому либо языку или фреймворку, поэтому эта статья может быть полезна широкой аудитории разработчиков.

Всем привет! Хабраюзер shai_xylyd написал статью про аспекты тестирования, где им были рассмотрены некоторые понятия и ценности TDD. В частности, он упомянул очень интересный способ создания первичных юнит-тестов — когда функциональный код пишется совместно с кодом юнит-теста, чем меня очень заинтриговал.

Дело в том, что я (как программист), нахожусь в состоянии переходного процесса между «классической» разработкой и разработкой test-driven, поэтому всякими способами ищу возможности упростить и сделать более естественной последнюю. После пары приседаний, сразу включиться в методику shai_xylyd не сумел. Начал переписку с автором статьи, где он натолкнул меня на мысль подойти к решению с математической точки зрения. Идея в том, чтобы воспользоваться функциональным пространством среды программирования и «разложить» написание юнит-теста на составляющие. После чего сделать выводы.