Есть ли работоспособный подход к использованию Test Driven Development в приложении COBOL? - PullRequest
Новая
       3

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

23 голосов
/ 31 марта 2011

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

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

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

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

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

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

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

Ответы [ 3 ]

1 голос
/ 05 апреля 2011

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

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

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

0 голосов
/ 03 декабря 2013

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

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

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

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

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

0 голосов
/ 04 апреля 2011

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

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

...