Есть ли работоспособный подход к использованию разработки через тестирование в приложении COBOL?
Существует, конечно, серая область между ними, однако я определил бы следующим образом:
Управление версиями инициировано действием 'записи', где, поскольку резервное копирование обычно инициировано временным интервалом.
Программное обеспечение для резервного копирования может быть настроено, чтобы работать каждую секунду и не хранить данные, если никакие изменения не произошли, но это недостаточно, чтобы это считали управлением версиями в моих глазах, так как для файла возможно измениться дважды за секунду.
3 ответа
Может быть, проверить QA Hiperstation . Хотя может стоить дорого (как и любой другой мэйнфреймовый продукт).
Использовал его только недолго, поэтому не может претендовать на звание эксперта. Я использовал его для запуска и проверки набора регрессионных тестов в среде типа COBOL / CICS / DB2 / MQ-SERIES и нашел его достаточно эффективным и гибким.
Я бы сказал, что это может быть одной из частей вашей головоломки, но, конечно, не все.
Независимо от того, как вы строите / запускаете модульные тесты, вам, вероятно, понадобится сводная информация о том, насколько хороши тесты и насколько хорошо протестировано полученное программное обеспечение.
См. Наш SD COBOL Test Coverage инструмент , специально разработанный для IBM COBOL.
Этот ответ может быть не таким простым, как вы (и я) надеялись.
Я слышал о COBOLunit и раньше, но я также не думаю, что он поддерживается в настоящее время ( https://sites.google.com/site/cobolunit/download ).
Наша команда разрабатывает корпоративный программный продукт для управления автосалонами Auto / Truck / Ag, подавляющее большинство которых находится в AcuCOBOL.
Мы смогли преодолеть некоторые препятствия, возможно, используя junit (модульное тестирование для Java) для выполнения и оценки модульных тестов COBOL.
Для этого потребовался специальный тестовый адаптер, который может служить в качестве конвейера и проводки для данных между модульными тестами COBOL и инфраструктурой Junit. В тестируемом приложении нам потребуется добавить / спроектировать хуки, которые будут оценивать входные данные как данные тестового примера, выполнять тест, к которому относятся эти данные, и сообщать результаты адаптеру. Мы находимся в начале этого эксперимента и не прошли много времени от этапа «возможно» до «он ценен». Первая предполагаемая загвоздка (которая, как мне кажется, существует во всех тдд), заключается в том, как встроить в программу жгуты.