Существует ли приемлемый подход к использованию Test Driven Development в приложении COBOL?

Кто-нибудь сталкивается с любыми практичными подходами к внедрению Test Driven Development (и, возможно, Driven Driven Development) в/для приложений COBOL?

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

Я видел http://sites.google.com/site/cobolunit/, и это выглядит интересно. Кто-нибудь видел это, работая в гневе? Это сработало? Каковы были ошибки?

Просто чтобы ваши творческие соки текли, некоторые "требования" для идеального подхода:

Обязательно разрешить интеграционный тест для реализации всей программы cobol.
Обязательно разрешать тесты для самостоятельной сертификации своих результатов (т.е. делать утверждения a la xUnit)
Должен поддерживать как пакетный режим, так и CICS cobol.
Если разрешить unit test выполнять отдельные абзацы внутри программы cobol, манипулируя рабочим хранилищем до/после вызова тестируемого кода.
Должно предоставить возможность автоматически выполнять серию тестов (комплект) и сообщать об общем результате.
Следует поддерживать использование тестовых данных, которые настроены перед тестом и затем сбрасываются.
Должно чисто отделить тест от производственного кода.
Если предлагает типичный тест на коэффициент производственного кода около 1:1 (т.е. при написании тестов не следует умножать количество кода, написанного настолько, что общая стоимость обслуживания увеличивается вместо вниз)
Не следует требовать от разработчиков COBOL изучения другого языка программирования, если только это не противоречит указанному выше требованию.
Может поддерживать отчеты о покрытии кода.
Могли поощрять принятие различных шаблонов проектирования в самом коде, чтобы сделать код более легким для тестирования.

Комментарии приветствуются с обоснованностью/уместностью вышеуказанных требований.

Напоминаем, что то, что я ищу здесь, является хорошим практическим советом по наилучшему способу достижения таких вещей - я не обязательно ожидаю предварительно упакованного решения. Я был бы доволен примером того, где кто-то успешно использовал TDD в cobol, вместе с некоторыми указаниями и gotchas о том, что работает, а что нет.

Ответ 1

Возможно, зайдите QA Hiperstation. Может стоить очень дорого (как и у любого другого продукта мэйнфрейма).

Используется только ненадолго, поэтому не может претендовать на роль эксперта. Я использовал его для запуска и проверки батареи регрессионных тестов в среде типа COBOL/CICS/DB2/MQ-SERIES и нашел ее достаточно эффективной и гибкой.

Я бы сказал, что это может быть одной из частей вашей головоломки, но, конечно, не все.

Ответ 2

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

См. наш инструмент SD COBOL Test Coverage, специально разработанный для IBM COBOL.

Ответ 3

Этот ответ может быть не таким простым, как вы (и я) надеялись.

Ранее я слышал о COBOLunit, но я также не думаю, что его в настоящее время поддерживаются (https://sites.google.com/site/cobolunit/download).

Наша команда разрабатывает корпоративный программный продукт для управления дилерами Auto/Truck/Ag, подавляющее большинство которых находится в AcuCOBOL.

Мы смогли сломать некоторые основания, возможно, используя junit (модульное тестирование для java) для выполнения и оценки модульных тестов COBOL.

Для этого потребовался настраиваемый тестовый адаптер, который может служить в качестве трубопровода и проводки для данных между модульными тестами COBOL и инфраструктурой Junit. В тестируемом приложении нам нужно будет добавлять/проектировать крючки, которые будут оценивать ввод как данные тестового случая, выполнять тест, к которому относятся данные, и сообщать результаты адаптеру. Мы находимся в начале этого эксперимента и не прошли мимо "возможного" этапа в "это ценное". Первая предвидимая ошибка (которая, как мне кажется, существует во всех tdd), заключается в том, как создавать упряжи в программе.