Как я могу обнаружить критические изменения WCF в моей сборке CI

Question

Я хочу автоматически проверить, есть ли в моих операциях WCF и контрактах с данными изменения между сборками CI.

РЕДАКТИРОВАТЬ: Я думаю об этом, как автоматический тест интеграции Аддитивные изменения в контрактах WCF не должны пройти проверку. Срочные изменения должны провалиться.

Я хочу знать момент, когда он сломался. Аддитивные изменения не нарушают контракты.

Есть идеи?

Answer 1

Если вы разбиваете свои контракты на отдельную сборку, а затем ссылаетесь на нее как с клиента, так и с сервера, то любые критические изменения будут обнаружены сразу после компиляции.Обмен ссылками, подобным этому, был рассмотрен здесь много раз на SO, поэтому я не буду его повторять.

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

Answer 2

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

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

Answer 3

Прежде всего, если вы думаете об автоматическом выполнении «Обновления ссылки на службу» в вашей сборке CI для каждой ссылки на службу, подумайте еще раз. Вы не хотите этого делать - вы хотите думать об этом заранее, делать обновления для каждого ссылающегося проекта, создавать их локально, запускать их тесты и т. Д. Вы не хотите, чтобы сборка делала это для вас только потому, что в договоре произошли изменения - клиенты могут еще не прочитать о таком изменении.

Во-вторых, я думаю, что единственное полезное определение «критических изменений» в этом контексте - запустить все ваши автоматические тесты и посмотреть, не произойдет ли разрыв. Это то, для чего предназначены CI-тесты в контексте другого кода; почему это отличается от услуг?