Модульные тесты имеют много полезных свойств: они позволяют запустить маленькую часть кода и убедиться в его работоспособности, они помогают осуществлять рефакторинг, служат “страховочной” сетью для любых изменений в коде и т.д. Существует противоречивое мнение, что модульные тесты могут являться документацией к модулю, классу, методу или просто части кода. Одни с ним соглашаются, другие твердят, что тесты невозможно читать и тяжело понять какая функциональность скрыта в самом коде. Я разделяю мнение обеих сторон. Если не уделять внимания тестам и писать их по принципу “для галочки”, то использовать их в качестве документации крайне сложно. Если же заранее вкладывать документирование кода в задачу модульных тестов, то это вполне реальная цель.

Эта статья будет не о том, как нужно писать тесты. Речь пойдет о именовании тестов. Примеры я буду приводить на Java, так как это мой “родной” язык (после русского и белорусского). Большая часть модульных тестов пишется с использованием JUnit или TestNG. Эти инструменты уже не накладывают на разработчика правил именования тестовых методов (в прошлом JUnit требовал, чтобы тесты начинались с префикса ‘test’). Достаточно лишь пометить метод тестового класса соответствующей аннотацией @Test. И это здорово, потому что вы можете выбирать любое имя, которое вам удобно.

Этой возможностью можно и нужно пользоваться. Название тестового метода должно отражать суть тестируемой функциональности. Например “if no signal groups with required type return empty set” может быть записано как “ifNoSignalGroupsWithRequiredTypeReturnEmptySet”. Вроде бы все логично, но воспринимать такое имя не так просто как кажется. Все дело в разделителях, к которым мы привыкли при чтении текста. К сожалению нельзя использовать пробелы в имени метода. Можно использовать другие разделители, например ‘_’. Приведенный выше пример превращается в “if_No_Signal_Groups_With_Required_Type_Return_Empty_Set”. Это уже лучше. Но есть еще одна проблема. Документацию хотелось бы видеть в более удобном формате, к примеру в виде списка возможностей.

И тут вам на помощь приходит IDE. Я обнаружил замечательный инструмент под названием TestDox (стыд мне и позор, что я обнаружил его только сейчас). Он решает все описанные выше проблемы и позволяет создавать, изменять и просматривать все тесты в виде обычного текста. Данный инструмент работает в виде плагина к IDE и может быть использован с разными языками программирования. Ниже приводится пару скриншотов его работы с комментариями:

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

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

У данного инструмента есть еще настройки, но их изучение оставлю вам в качестве домашнего задания. Пишите свои тесты так, чтобы они приносили максимум прибыли в будущем. С помощью описанного инструмента ваши модульные тесты могут быть настоящей документацией, не хуже комментариев.