Обработка изменений в интерфейсе, совместно используемом несколькими решениями?

Question

Нашим «основным» решением является код разработки: общие библиотеки, сервисы, проекты пользовательского интерфейса и т. Д. Другое решение - это решение для интеграции и автоматизированного тестирования. Он ссылается на несколько проектов развития. Причина заключается в том, чтобы избежать вмешательства в файл VSMDI модульного тестирования решения для разработки. И позволить нам играть с различными методами выполнения (другими участниками тестирования, такими как Gallio или StoryTeller), не вмешиваясь в решение для разработки.

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

У кого-нибудь есть подобная настройка? Как вы решаете эти проблемы, соблюдаете ли вы строгую процедуру или есть какой-то технический ответ?

Answer 1

Один из подходов состоит в том, чтобы извлечь любые общие интерфейсы в определенный каталог, а затем использовать вашу систему управления версиями, чтобы убедиться, что каталог одинаков для обоих проектов - например, если вы использовали Subversion, он имеет функцию называется " externals ", что позволяет одному проекту содержать каталог, который фактически является ссылкой на указанный каталог (или указанную версию указанного каталога) в другом проекте.

Answer 2

Я переместил весь свой неисполняемый код тестовой инфраструктуры в один проект. Сейчас оно в разработке и тестировании. Таким образом, если код разработки автоматически подвергается рефакторингу, он изменяется в моем проекте. Если в интерфейс вносятся критические изменения, они становятся ошибками во время компиляции.

Answer 3

Если ваш макет реализует интерфейс из ссылочного проекта, то этот проект должен быть построен вместе с остальными тестовыми проектами. Если это действительно не так, проверьте порядок сборки / конфигурации сборки в visual studio.

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