Существует ли приемлемый подход к использованию 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), заключается в том, как создавать упряжи в программе.