Юнит-тестирование на процедурных или функциональных языках программирования

Question

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

Как крупные проекты C, такие как Perl или Ruby или даже ядро ​​Linux, выполняют модульное тестирование? Или даже на любом функциональном языке?

Мне знакомы Внедрение зависимостей и Абстрактная фабрика для тестирования в ООП, но я не вижу масштабируемой и управляемой эквивалентности в неООП. Например, в C или Haskell будут слои над слоями функций, более высокие из которых неявно вызывают нижние. Как найти швы для проверки только блока кода вместо всех его зависимостей?

Один из способов избежать необходимости соединять все швы - поддерживать очень низкую глубину графа зависимости вызовов. Код горизонтально, а не вертикально, так сказать. Сохраняйте как можно больше логики приложения в «листовых» функциях; и убедитесь, что функции «узла» не работают, кроме передачи данных в другие функции узла / листа. Затем проверьте только «листовые» функции; оставьте функции "узла" вне интеграционных тестов. Этот подход эффективен?

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

Answer 1

Функциональные языки имеют другие конструкции (кроме объектов) для модульности, такие как функторы ML.«Внедрение зависимостей» - это, в основном, прославленное имя для «абстрагирования над вещами», и оно веками использовалось в функциональных языках.

Тестирование во всех парадигмах должно соответствовать границам спецификации.Если у вас есть представление о том, что должен делать данный фрагмент кода (функция, метод, объект ...), вам следует проверить его соответствие этой спецификации.Для конечных функций это будет модульное тестирование, для функции «узел» это можно считать «интеграционным тестированием», если хотите, но на самом деле это одно и то же действие.применяется к функциональному программированию, с практически одинаковыми результатами;в частности, (пере) проектирование кода для удобства тестирования также улучшает его модульность и удобство обслуживания.

Answer 2

проектирование кода для удобства тестирования также улучшает его модульность и удобство обслуживания.

Не правда. Разработка кода, облегчающего тестирование, упрощает написание тестового кода.

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