Как вы думаете, юнит-тесты - хороший способ показать вашим коллегам-программистам, как использовать API?

Question

Как вы думаете, юнит-тесты - хороший способ показать вашим коллегам-программистам, как использовать API?

Я слушал подкаст Stackoverflow на этой неделе и теперь я понимаю, что модульное тестирование не подходит для всех ситуаций (т. Е. Это может стоить вам времени, если вы пойдете на 100% покрытие кода). Я согласен с этим, поскольку в прошлом я страдал от «расстройства покрытия кода ОКР» и теперь исправил свои ошибки.

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

Answer 1

Я думаю, что модульное тестирование - это фантастический способ документировать API. Он не обязательно заменяет хорошие комментарии или документацию по API, но это очень практичный способ помочь людям разобраться в мелочах вашего кода. Более того, хорошее модульное тестирование способствует хорошему дизайну, поэтому в результате ваш код будет легче понять.

Answer 2

Нет. Тесты можно использовать в качестве вторичной ссылки, они, по крайней мере, имеют то преимущество, что являются примерами, которые на самом деле компилируются, но они не заменяют хорошую документацию API.

Остерегайтесь фанатиков, претендующих на почти мистические способности для модульных тестов, говоря что-то вроде «тесты - это дизайн», «тесты - это спецификация», «тесты - это документация». Нет. Тесты - это тесты, и они не дают вам повода срезать углы в другом месте.

Answer 3

Хорошая документация обычно включает хорошие примеры. Мне трудно представить лучший набор примеров, чем те, которые показывают, что ожидается от правильной реализации!

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

Answer 4

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

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

Наконец, содержимое модульных тестов, как правило, не так доступно для инструментов генерации документации и, как правило, отделено от кода, который они тестируют (несмотря на странности, подобные документированию Python).

Answer 5

Документация не должна заменяться кодом модульного тестирования, точка.

Документация предназначена для программиста, который пытается использовать и понимать ваш API.

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

Документация должна постепенно накапливаться, модульные тесты должны быть как можно более простыми, но настолько сложными, насколько это необходимо для проверки функциональности.

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

Вместо того, чтобы пользователь вашего API расшифровал эти модульные тесты, выясните различия и выясните, почему это должно приводить к другому (или, возможно, одинаковому) поведению, что не является хорошим учебным пособием.

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

Документация предназначена для программистов, которые будут использовать ваш API.

Это не одна и та же целевая аудитория.

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

Answer 6

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

Например, библиотека Math хорошо протестирована модульно. Если у кого-то есть вопрос (например, как найти информацию о пересечениях луч / объем), то первое, что я посылаю ему, - это модульные тесты.

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

FWIW Я думал, что на этой неделе обсуждение подкастов по модульному тестированию было на ура. Модульное тестирование (и разработка через тестирование) является отличным методом для разработки компонентов вашего приложения, но для тестирования самого приложения вы быстро достигаете точки, когда код, необходимый для тестирования, становится непропорциональным и хрупким.