Продолжение темы использования библиотеки контрактного тестирования Pact для .NET. В первой части темы были рассмотрены теория и процесс контрактного тестирования взаимодействий по HTTP.

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

В этой статье подробнее остановимся на тестировании асинхронных коммуникаций на примере RabbitMq, а также познакомимся с инструментом PactBroker.

Необходимость написания тестов каждый определяет сам для себя. Модульные и интеграционные тесты вполне могут спасти нас от ошибок, вызванных нашей забывчивостью: убрали проверку на null или удалили строку сохранения сущности в БД? Хороший тест скорее всего обратит наше внимание на эту оплошность, и мы исправим её ещё до того, как задача перейдёт в стадию тестирования.

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

Есть ли способ зафиксировать контракт, обеспечить его неизменяемость и сделать результаты тестирования наглядными для всех участников взаимодействия? Да, библиотека Pact позволяет писать кроссплатформенные контрактные тесты, в результатах которых заинтересованы сразу несколько систем.