Метрики покрытия кода тестами

Если код написан в объектно-ориентированном дизайне, есть еще один:

• Проверка того, ведут ли себя классы, объекты и методы или доменный язык так, как они должны

Это промежуточный уровень, который соединяет уровень кода с уровнем продукта.

видения

Важно различать, что у нас есть не только три уровня проверок, но и три уровня видения:

• Первое «должно быть сделано» — это видение разработчика, написавшего код. Если вы спросите его, для чего нужна эта подпрограмма, он объяснит ее на уровне кода, как она манипулирует переменными, вычисляет результаты и так далее.
• В противоположность этому, второе «таким образом, как было задумано» — это не видение разработчика, а на самом деле видение стейкхолдера. Это на уровне продукта, а не на уровне кода. Если вы спросите продакт-менеджера, для чего эта функция хороша, он объяснит ее на уровне продукта — сценарии и варианты использования, цели продукта и дизайн сервиса.
• Третье «должно быть», на мой взгляд, является решающим для долгосрочных успешных проектов развития. Это мост между уровнем кода и уровнем продукта — например, наличие объектно-ориентированного архитектора программного обеспечения, понимающего как язык продукта, так и язык программирования, и создание нового доменного языка для предметной области > Это понимают оба уровня.

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

Именно в этом суть объектно-ориентированной разработки — и определенно не в том, чтобы упростить решение задач на уровне кода, используя объекты, классы и экземпляры вместо жонглирования выделением памяти и указателями.

покрытие

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

• Если вы хотите проверить уровень кода, покройте их модульными тестами. Использование процента покрытия строк кода в качестве индикатора покрытия имеет смысл, поскольку модульные тесты фокусируются на реальных вещах, происходящих в каждом выражении. Немного лучше было бы использовать процент покрытия выражений, так как вы хотите проверять не файлы с кодом, а сам код.
• Если вы хотите проверить уровень продукта, вы должны написать проверки, ориентированные на варианты использования с тестами функций. Поскольку уровень продукта не зависит от кода, любой индикатор, основанный на коде, не имеет смысла. Я бы посоветовал скорее пойти на продукт, основанный на продукте. Хорошо задокументированный продукт (можно с уверенностью сказать, что я никогда его не видел) имеет структуру продукта. Итак, чего вы хотели бы добиться, так это покрыть весь граф разбивки продукта проверками. Назовем это: элементы разбивки по продуктам (или функции) процент покрытия.
• Для проверки уровня доменного языка потребуется полностью понять язык, а затем написать проверки для объектов, классов и методов. Интересно, что эти проверки также называются модульными тестами, потому что на уровне кода они выполняют одну и ту же задачу. Но с точки зрения продукта они будут называться тестами функций, поскольку эти модульные тесты охватывают функции. Это мост, который мы создали для развития, отраженный в автоматических проверках. Итак, что будет лучшим индикатором покрытия для уровня доменного языка? Я бы сказал, что это процент охваченных элементов языка домена, потому что вы хотите охватить все существительные, глаголы и прилагательные этого языка.

автоматизированные проверки

Итак, теперь вы хотите спросить: «А не является ли доменный язык просто мостом между уровнем кода и уровнем продукта, поэтому его проверка совершенно излишня?»

Я бы сказал: «Да! Да! и да!!!"

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

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

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

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