Контроль версий - заглушки и издевательства

Question

Ради этого вопроса меня не волнует разница между заглушками, насмешками, манекенами, подделками и т. Д.

Допустим, я работаю над проектом с другим человеком. Я работаю над компонентом A, а он работает над компонентом B. Они работают вместе, поэтому я заглушаю B для тестирования, а он заглушает A. Мы работаем в DVCS, скажем, Git, потому что это действительно так здесь.

Когда приходит время объединить наши компоненты, нам нужно получить «настоящие» файлы от моего А и его Б, но выбросить все фальшивые вещи. Во время разработки вполне вероятно (если только мне не нужно научиться правильно оштуковывать вещи), что подделки имеют те же имена файлов и классов, что и настоящие.

Итак, мой вопрос: какова правильная процедура для контроля версий на подделках, и как правильно объединяются компоненты, гарантируя, что они схватят реальную вещь, а не подделку? Я полагаю, что один из способов - просто выполнить слияние, ожидать, что он скажет CONFLICT, а затем вручную удалить весь фальшивый код из полуслитых файлов. Но это звучит скучно и неэффективно.

Разве фальшивые вещи вообще не идут под ВК? Должны ли они быть разорваны непосредственно перед слиянием? Извините, если ответ на этот вопрос будет очевидным или тривиальным, я просто ищу здесь «предложенную практику».

edit: еще немного информации, которую я не осознавал, окажется важной. Я конкретно говорю о веб-разработке, точнее, я НЕ говорю о .NET-разработке. Моя история, кажется, ввела в заблуждение людей в этом отношении.

Answer 1

Итак, в основном это ситуация (чтобы убедиться, что я правильно понимаю):

• Модульные тесты для компонента A написаны для поддельного компонента Bs
• Компонент B не был готов, но теперь он
• Вы хотите реорганизовать тесты, чтобы использовать реальный компонент B вместо подделок

Я бы на самом деле не рекомендовал делать этот последний шаг. Я бы оставил существующие модульные тесты для A, написанные для поддельных Bs , потому что они должны были проверять A. Теперь, когда A и B готовы, я бы написал новый набор Интеграция тесты, которые проверяют взаимодействие между A и B .

Что касается подделок и реальных классов, имеющих одинаковые имена, я бы исправил это с некоторой политикой, с которой вы и другой разработчик договорились о том, где хранить подделки в файловой структуре, в отличие от реальных классов.

Answer 2

Подделки должны все еще находиться в системе контроля версий, вероятно, в другом пакете / пространстве имен, чтобы их могли использовать модульные тесты. Имейте интеграционные тесты, которые используют оба реальных компонента, но держат модульные тесты изолированными.

Ваш производственный код должен ссылаться на интерфейсы или абстрактные базовые классы, и в него должны быть внедрены реализации, чтобы вы могли использовать подделки для тестирования, но производственные классы для реальной вещи.

Answer 3

Для git есть файл .gitignore, который позволяет вам не включать файлы в систему контроля версий.

Также вы должны использовать динамический макет, если это возможно. Для .NET что-то вроде Rhino.Mock или Moq позволяет программно создавать макеты вместо хранения файлов и подделок.