[Николай Иванович Приходько 0]

Вам же в 4 и 7 посту всё описали. обычно "заглушки" :) все сами себе и пишут.

А в чём же тогда выгода раздельной разработки? Если я буду должен написать заглушки для всех 853-х модулей о которых я понятия не имею (ведь ими занимаются мои коллеги и они знают об этих модулях всё и кто как не они смогут написать заглушку своего модуля лучше всего)

[Demeny 0]

Для отладки своего куска кода большого программного продукта отдельно от остальных можно пользоваться технологией "юнит тестов" (unit tests).

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

Например, Вы пишете функцию вычисления синуса double my_sinus(double angle). Тогда очевидным юнит-тестом для неё будет программа, вызывающая её с набором известных значений и анализирующая результаты на правильность (по таблице Брадиса :) ), а также вызывающая её с заведомо гигантскими аргументами.

Данный подход очень схож с тестбенчами в разработке FPGA ядер.

[Harbour 0]

в идеале тест должен быть написан так чтобы код прошел по coverage на 100%. Ясен пень - это никак не гарантирует, что при сборке модуля, из-за архитектурных просчетов, что-то будет вообще работать