CC BY
16УДК 004
Пеганов Д.Д.
Тестировщик Программного Обеспечения в ЗАО «ТекХайв» (г. Торревьеха, Испания)
УСКОРЕНИЕ РАЗРАБОТКИ ЧЕРЕЗ КОНТРАКТНОЕ ТЕСТИРОВАНИЕ С GO И PACT
Аннотация: ускорение разработки через контрактное тестирование с Go и Pact" -это экспертная статья, написанная автором с целью исследования и анализа сложностей, возникающих при автоматизированном тестировании в современном мире программного обеспечения. В ситуации, когда системы становятся все более сложными и взаимодействуют друг с другом и с множеством сторонних сервисов, подходы к тестированию требуют глубокого понимания и новаторских решений. Основной фокус автора направлен на концепцию контрактного тестирования - инновационного подхода, основанного на определении и проверке контрактов между компонентами системы. Это дает возможность создавать единообразные и предсказуемые интерфейсы, выявлять потенциальные проблемы взаимодействия компонентов на ранних стадиях разработки и облегчать командное взаимодействие. Автор подробно анализирует и обсуждает различные аспекты контрактного тестирования, акцентируя внимание на его роли в обнаружении и устранении ошибок, обеспечении согласованности и понимания между всеми участниками проекта. Результаты исследования подтверждают основные предположения и демонстрируют важность и эффективность контрактного тестирования в ускорении процесса разработки программного обеспечения.
Ключевые слова: язык ГО, тестирование приложений, программное обеспечение.
Введение в контрактное тестирование
В современном мире программного обеспечения, где сложные системы взаимодействуют друг с другом и с множеством сторонних сервисов, надежность и согласованность становятся критически важными аспектами разработки. Одной из частых проблем автоматизированного тестирования таких систем
являются изменения в компонентах, принадлежащих другим командам разработки. Это происходит, когда команды не уведомляют друг друга вовремя о внесенных изменениях, что приводит к неожиданным сбоям и проблемам взаимодействия между компонентами. Здесь на помощь приходит контрактное тестирование - практика, которая позволяет обеспечить непрерывное и безопасное функционирование системы.
Что же такое контрактное тестирование? Контрактное тестирование представляет собой подход к тестированию программного обеспечения, основанный на определении и проверке контрактов между компонентами системы. Контракты, которые являются спецификацией взаимодействия между компонентами, определяют ожидаемое поведение, формат передаваемых данных и другие соглашения. Такие компоненты обычно принадлежат разным командам разработки программного обеспечения, что делает этот тип тестирования достаточно сложным в реализации, но не менее важным.
Цели данной статьи:
1. Объяснить концепцию контрактного тестирования, демонстрируя его ключевые принципы и преимущества.
2. Показать, как контрактное тестирование может помочь создавать единообразные и предсказуемые интерфейсы, что облегчает интеграцию компонентов и упрощает поддержку.
3. Продемонстрировать, как контрактное тестирование может выявить возможные проблемы взаимодействия компонентов на ранних стадиях разработки, что позволяет проводить интеграционное тестирование, даже если реализация некоторых компонентов еще не завершена.
4. Наглядно показать, как контрактное тестирование способствует быстрому обнаружению и исправлению ошибок, обеспечивая обнаружение нарушений контрактов и помогая идентифицировать причину проблемы.
5. Подчеркнуть, как контрактное тестирование упрощает командное взаимодействие и сотрудничество, становясь языком взаимодействия, который
помогает установить и поддерживать согласованность и понимание между всеми участниками проекта.
Обзор литературы
Важность и значимость контрактного тестирования в современной разработке программного обеспечения подчеркиваются во многих научных работах. Так, в своей статье 2018 года "Contract-based testing for web service integrations: a systematic mapping study", Ди Лео, Зампиванеа и соавторы рассматривают контрактное тестирование как эффективный инструмент, позволяющий командам разработки обнаруживать несогласованности между компонентами на ранних стадиях разработки. Авторы утверждают, что этот подход значительно улучшает качество ПО и ускоряет процесс его разработки [1].
В то же время Волфсон в своей работе 2019 года "Building Microservices with Contract Testing" подчеркивает, что контрактное тестирование способствует созданию более предсказуемых и единообразных интерфейсов [2]. Он утверждает, что благодаря контрактному тестированию, разработчики могут быстрее обнаруживать и исправлять ошибки, экономя при этом время и ресурсы. Волфсон также акцентирует внимание на том, что контрактное тестирование может служить своего рода "общим языком" для команд разработки, способствуя более эффективной коммуникации и координации действий.
В условиях, когда количество и сложность взаимосвязанных систем постоянно увеличиваются, контрактное тестирование становится критически важным элементом эффективной разработки ПО. Несмотря на это, многие команды разработки еще не полностью интегрировали его в свои рабочие процессы. Моя статья предлагает конкретные рекомендации по использованию Go и Pact, двух актуальных инструментов в области контрактного тестирования, и я надеюсь, что она станет ценным ресурсом для разработчиков, стремящихся улучшить свои процессы и ускорить разработку.
Что такое Pact
Pact - популярный инструмент для контрактного тестирования, который предоставляет фреймворк для реализации данного типа тестирования на различных языках, включая Go. Pact работает путем генерации поддельных серверов, которые моделируют поведение провайдера системы, позволяя клиентской системе тестировать взаимодействие с провайдером и создавать контракт, определяющий ожидаемое поведение провайдера.
Pact использует подход контрактного тестирования, основанный на ожиданиях клиента (системы, инициирующей коммуникацию). Клиент определяет ожидаемое поведение провайдера (системы, принимающей коммуникацию) в виде контракта. Контракт содержит информацию о запросах, которые клиент будет отправлять провайдеру, и ожидаемых ответах, которые провайдер должен вернуть.
С помощью Pact клиент может имитировать сервер, который имитирует поведение провайдера на основе определенного контракта. Затем клиент может взаимодействовать с поддельным сервером, отправлять запросы и проверять ответы, чтобы убедиться, что они соответствуют ожидаемому поведению. Такой подход позволяет клиенту тестировать интеграцию с провайдером, даже если фактическая реализация провайдера еще не доступна. Работа с контрактом производится на уровне unit-тестов (тип тестирования, при котором отдельные модули проверяются на корректность).
После того, как клиент протестировал свои взаимодействия и убедился в соответствии провайдера ожидаемому поведению, сгенерированный контракт становится ценным артефактом. Контракт может быть передан команде провайдера, которая может использовать его для проверки соответствия своей реализации согласованному контракту. Это помогает поддерживать согласованность и совместимость между клиентской и провайдерской системами [3]. Схема генерации и проверки контракта представлена на Рисунке 1.
Рисунок 1: Схема генерации и проверки контракта. Contract generation and verification scheme.
В контексте Go, одного из самых популярных языков программирования микросервисов [6], для работы с Pact доступна библиотека Pact Go. Она предлагает набор инструментов и утилит для написания тестов клиента и провайдера. Библиотека включает "поддельный" сервер, который имитирует поведение провайдера, позволяя клиенту проводить тестирование взаимодействия и создавать контракт.
Используя Pact и библиотеку Pact Go, разработчики могут эффективно реализовывать контрактное тестирование на языке Go, обеспечивая совместимость и надежность своих программных систем.
Pact в действии
Тестирование с Pact обычно включает в себя два этапа: тестирование клиента и тестирование провайдера. На этапе тестирования клиента приложение -клиент отправляет запросы на поддельный сервер, предоставленный Pact, и поддельный сервер создает контракт на основе обмениваемых запросов и ответов.
На этапе тестирования провайдера приложение-провайдер проверяется на соответствие контракту, сгенерированному на первом этапе, чтобы убедиться, что оно может обрабатывать запросы и предоставлять ожидаемые ответы.
Далее я продемонстрирую небольшой пример с реальными примерами использования Pact с Go, поскольку считаю, что это отличный способ предоставить практическое понимание того, как использовать инструмент с реальным сценарием. Это позволит увидеть инструмент в действии и понять, как его можно интегрировать существующие проекты.
Установка Pact
Начать стоить с установки Pact. Это не требует больших усилий и я советую следовать официальной инструкции Pact [4].
Сервис провайдера
В качестве провайдера будет использоваться простой API-сервис "Car", который я подготовил специально для этой статьи. Этот сервис поддерживает 2 метода:
• GET — для получения информации о конкретной машине на основе предоставленного ID.
• POST — для сохранения новой машины в системе.
API-сервис "Car":
type Car struct {
ID string json:"id"
Title string j son: "title"
Color string json:"color"
}
var Cars = []Car{
{ID: "1", Title: "BMW", Color: "Black"}, {ID: "2", Title: "Tesla", Color: "Red"},
}
func main() {
router := gin.Default() router.GET("/cars/: id", getCarByID) router.POST("/cars", createCar)
err := router.Run("localhost:8080") if err != nil {
log.Infof("Failed to start you service")
}
}
func getCarByID(c *gin.Context) { for _, car := range Cars {
if car.ID == c.Param("id") {
c.IndentedJSON(http. StatusOK, car) return
}
}
// Return 404 Status Code and error message if no car was found. c.IndentedJSON(http.StatusNotFound,
gin.H{"message": "Requested car is not found"})
}
func createCar(c *gin.Context) { var newCar Car err := c.BindJSON(&newCar)
// Return 400 Status Code and error message if provided data is invalid. if err != nil {
c.IndentedJSON(http.StatusBadRequest,
gin.H{"message": "Invalid data provided"})
return
}
// Return 400 Status Code and error message if no ID was provided. if newCar.ID == "" {
c.IndentedJSON(http.StatusBadRequest,
gin.H{"message": "ID must not be empty"})
return
}
Cars = append(Cars, newCar) c.IndentedJSON(http. StatusCreated, newCar)
}
Тест клиента
Изначальный файл с тестами клиента (генерацией контракта) выглядит так:
var pact dsl.Pact
var dir, _ = os.Getwd()
var pactDir = fmtSprintf("%s/pacts", dir)
var logDir = fmt.Sprintf("%s/log", dir)
type Car struct {
ID string json:"id" Title string j son: "title" Color string json:"color"
}
func createPact() dsl.Pact { return dsl.Pact {
Consumer: "Sample Consumer", Provider: "Sample Provider", LogDir: logDir, PactDir: pactDir,
}
}
func TestMain(m *testing.M) {
// Setup Pact and related test stuff pact = createPact()
// Proactively start service to get access to the port pact.Setup(true)
// Run all the tests code := m.Run()
// Shutdown the Mock Service and write pact files to disk err := pact.WritePact() if err != nil {
log.Infof("Failed to write your contract") return
}
pact.Teardown() os.Exit(code)
}
func getCar() (err error) {
url := fmt.Sprintf("http://localhost:%d/cars/1", pact.Server.Port) req, _ := http.NewRequest("GET", url, nil) req.Header.Set("Content-Type", "application/json")
http.DefaultClient.Do(req)
return
}
Стоит добавить несколько тестовых функций в тест клиента. Пример функции, валидирующей только некоторые значения в ответе провайдера:
func TestSomeKeys_GET(t *testing.T) { pact.
AddInteraction(). Given("Validate title only").
UponReceiving("A GET request"). WithRequest(dsl.Request{ Method: "GET",
Path: dsl.Term("/cars/1", 7cars/[0-9]+"), Headers: dsl.MapMatcher{
"Content-Type": dsl.Term("application/json;
charset=utf-8", application\/j son),
},
}).
WillRespondWith(dsl.Response{ Status: 200,
Body: map[string]interface{}{
// Key + value validation "title": "BMW",
// Validate exact key + the format of value "color": dsl.Term("Yellow", \w+),
},
Headers: dsl.MapMatcher{
"Content-Type" : dsl.Term("application/json;
charset=utf-8", applicationVj son),
},
})
err := pactVerify(getCar) if err != nil {
t.Fatalf("Error on Verify: %v", err)
}
Тестовый сервис не ограничен GET запросами, поэтому стоит добавить контракт функции, проверяющие работу с POST методом. Также, есть смысл добавить функцию, проверяющую поведение провайдера при получении некорректного ID. Вся эта валидация происходит на подобии с вышеупомянутой функцией проверки метода GET, поэтому я не буду приводить примеры таких функций здесь. Все тесты и файлы данной статьи доступны в моём кодовом репозитории [5].
Для запуска теста клиента и генерации контракта следует пользоваться терминальной командой go test в директории с тестовым файлом. Если контракт был сгенерирован корректно, то в результате должен быть вывод в консоли, представленный на Рисунке 2.
den^IN-S95P35K3NPM:/mnt/c/Users/den/api-server/HTTP-contract-testing/client$ go test 2023/05/01 11:21:19 [INFO] checking pact-mock-service within range >= 3.5.0, < 4.0.0 2023/05/01 11:21:19 [INFO] checking pact-provider-verifier within range >= 1.36.1, < 2.0.0 2023/05/01 11:21:20 [INFO] checking pact-broker within range >= 1.22.3 2023/05/01 11:21:20 [INFO] INFO WEBrick 1.3.1
2023/05/01 11:21:20 [INFO] INFO ruby 2.4.10 (2020-03-31) [x86_64-linux] 2023/05/01 11:21:20 [INFO] INFO WEBrick::HTTPServer#start: pid=176 port=36295 PASS
2023/05/01 11:21:20 [INFO] INFO going to shutdown ... 2023/05/01 11:21:21 [INFO] INFO WEBrick::HTTPServer#start done, ok HTTP-contract-testing/client 1.373s
Рисунок 2: Вывод консоли при успешной генерации контракта. Console output on successful contract generation.
Тест провайдера
Когда контракт создан, можно приступить к проверке соответствия провайдера сгенерированному контракту. Хорошая новость — это гораздо проще, чем генерация контракта. Пример теста провайдера:
func startProviderO { main()
}
func TestServerPact_Verification(t *testing.T) { go startProvider() var dir, _ = os.Getwd()
var pactDir = fmtSprmtf("%s/../client/pacts", dir) var logDir = fmtSprintf("%s/log", dir)
pact := &dsl.Pact{
Provider: "Sample Provider",
LogDir: logDir,
PactDir: pactDir,
DisableToolValidityCheck: true,
}
_, err := pact.VerifyProvider(t, types.VerifyRequest{ ProviderBaseURL: "http://127.0.0.1:8080", PactURLs: []strmg{"../client/pacts/sample_consumer-
sample_provider.j son"}, })
if err != nil {
t.Fatal(err)
}
}
Чтобы запустить тест провайдера и проверить соответствие работы сгенерированном контракту, снова поможет выполнение команды go test, но в данном случае запускать её следует в директории с файлом теста провайдера. Вывод консоли в случае успешного теста провайдера приведён на Рисунке 3.
ileiiiWlii-soSPlSKiNPMr/iirit/c/Uiert/defl/apl-tervrr/MnP-iiwitract-tettlJU/servirrS go test
[6IN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery aiddleware already attached.
[GIN-debug] [WARNING] Running in "debug" "»ode. Switch to "release" «ode in production. - using env: export GIN_MOOE-r*lease • using code: gin.SetMode(gin.Releaseflode)
[GIN debug| GET /cars/:id ••> HTTP-contract-testing/server.getCarByID (3 handlers)
[GIN-debug] POST /cars --» HTTP-contract-testing/servcr.createCar (3 handlers)
[GIN-debug] [WARNING] You trusted all proxies, this is NOT safe. We recooaend you to set a value. Please check https://pkg.go.dev/github.co«/gin-gonic/gin*read«e-doii-t-trust-all-proxies for details. [GIN debug] Listening and serving HTTP on localhost:8880
2023/05/01 11:21:26 (debug] start verification _
[GIN] 2023/05/01 - 11:21:26 |И|| 79.198ns | 127.0.0 1 "/cars"
[GIN] 2023/0S/01 - 11:21:26 I 2«< | 20.062(1* j 127.0.0 1 "/cars/1"
[GIN] 2023/05/01 11:21:26 j^Hi 18.017iis 1 127.0.0 1 "/cars/1"
[GIN] 2023/05/01 - 11:21:26 1 201 55.417(is j 127.0.0 1 "/cars*
[GIN] 2023/05/01 • 11:21:26 24.61 Iiis | 127.0.0 1 "/cars/9999
[GIN] 2023/05/01 - 11:21:26 I^Hl 44.097(is j 127.0.0 1 "/cars"
PASS
ok HTTP-contract-testing/server 8.6Sls
Рисунок 3. Вывод консоли при успешном тесте провайдера. Console output on successful provider test.
Как видно на Рисунке 3, в итоговом контракте проверяется 6 разных сценариев, включая GET и POST методы. Использование удалённого брокера
В приведенных выше примерах контракт хранится локально, но стоит рассмотреть и сервис PactFlow - это удаленный сервис, который предоставляет возможность командам управлять своими контрактами Pact удаленно. Он предоставляет централизованное место для хранения и управления контрактами, их версионирования и отслеживания истории. Для начала его использования понадобится только URL брокера и его токен. Для получения их, достаточно следовать инструкциям на сайте Pact
Flow [6]. Это простой и бесплатный процесс. Бесплатный план позволяет хранить до 5 контрактов, что более чем достаточно для начала. После создания учетной записи нужно внести несколько изменений в тесты. В файл тестирования клиента нужно добавить dsl.Publisher:
// Store contract remotely
publisher := dsl.Publisher{}
err = publisher.Publish(types.PublishRequest{
PactURLs: []string{"../client/pacts/sample_consumer-sample_provider.j son"},
PactBroker: "https://pen.pactflow.io/", //link to your remote
M
Contract broker
BrokerToken: "xxx", //your PactFlow token
ConsumerVersion: "1.0.0",
Tags: []string{"1.0.0", "latest"},
!!
})
if err != nil {
t.Fatal(err)
}
Также, следует обновить функцию pact.VerifyProvider в тесте провайдера:
_, err := pact.VerifyProvider(t, types.VerifyRequest{
ProviderBaseURL: "http://127.0.0.1:8080", //provider's
URL
M
BrokerURL: "https://pen.pactflow.io", //link to your
remote Contract broker
BrokerToken: "xxx", //your PactFlow token
M
!!
PublishVerificationResults: true, ProviderVersion: "1.0.0",
})
if err != nil {
t.Fatal(err)
}
// Uncomment to verify contract locally /*log.Println("[debug] start verification") _, err := pact.VerifyProvider(t, types.VerifyRequest{ ProviderBaseURL: "http://127.0.0.1:8080", PactURLs: []string{"../client/pacts/sample_consumer-sample_provider.j son"},
})
if err != nil {
t.Fatal(err)
}*/
После внесения вышеуказанных изменений, при выполнении в терминале команды go test, проверка будет выполняться с использованием удаленного контракта, и результаты проверки будут доступны в PactFlow. Интерфейс страницы PactFlow с сохранённым контрактом представлен на Рисунке 4.
»VERVIEW NETWORK DI.
Sample Consumer Sample Provider i с
1.0.0 1.0.0
V 1.0.0 BiVWCH N'A
Success (NVWNWWl
/Л ( ч/ ) N/A N'A 1 VIEW РАС T i
<ТТ>0 NM
4 minutes ago 2 minutes ago
Рисунок 4: Интерфейс страницы PactFlow с сохранённым контрактом. PactFlow page interface with the saved contract.
Удаленный брокер не ограничивается только PactFlow. Возможно использование образа Docker, предоставленного Pact [9]. Однако создание и поддержка собственного брокера может быть затратным по времени и затратам и может не являться самым эффективным вариантом. Некоторые альтернативы PactFlow включают:
• Самостоятельно размещенный брокер - команды могут создать свой собственный самостоятельно размещенный брокер контрактов с использованием инструментов, таких как Pact Broker, который является реализацией спецификации Pact с открытым исходным кодом. Однако создание и поддержка самостоятельно размещенного брокера может быть затратным по времени и потребовать специализированных навыков.
• Репозиторий Git - команды могут хранить свои контракты в репозитории Git и использовать систему контроля версий для управления изменениями и обновлениями контрактов. Однако этот
подход не предоставляет такой же уровень проверки контрактов и инструментов для совместной работы, как PactFlow.
• Общая файловая система - команды могут использовать общую файловую систему, такую как Dropbox [10] или Google Drive [11], для хранения и совместного использования контрактов. Однако этот подход может быть подвержен проблемам синхронизации. Хотя эти альтернативы могут подходить для некоторых команд, они могут не предоставлять такой же уровень функциональности, безопасности и удобства использования, как PactFlow. Поэтому, в зависимости от конкретных потребностей и ресурсов команды, PactFlow может быть наиболее эффективным вариантом для удаленного управления контрактами Pact.
Заключение и результаты внедрения контрактного тестирования С внедрением контрактного тестирования моей команде по разработке ПО удалось достичь впечатляющих результатов. Существующие автотесты перестали "падать" из-за изменений в системах, принадлежащих другим командам разработки. Это стало возможным из-за того, что контракты не позволяют вносить изменения в системы без обновления соответствующего контракта и, следовательно, без уведомления клиентской команды, которая использует этот контракт. На Рисунке 5 можно заметить значительное снижение числа "ненадёжных" тестов, начиная с августа, когда я применил контрактное тестирование. Фактически, количество таких тестов сократилось до нуля, что свидетельствует о значительном улучшении стабильности нашего продукта.
Отношение количества тестов с отрицательными результатами из-за изменений во внешних системах к общему числу тестов.
ISO
159
160 154 155
141
140 132
Месяц
■ Общее количество тестов
■ Количество тестов с отрицательными результатами из-за изменений во внешних системах
Рисунок 5: Отношение количества тестов с отрицательными результатами из-за изменений в системах, принадлежащих другим командам, к общему числу тестов.
Ratio of failed tests due to changes in systems owned by other teams to the total number of tests.
На Рисунке 6 представлено отношение количества всех тестов с отрицательными результатами, независимо от причины неудачного результата, к общему их числу. Из чего можно сделать вывод о том, что примерно половина тестов "падала" (имела отрицательный результат) из-за изменений, не относящихся к функционалу моей команды разработки ПО.
Отношение количества всех тестов с отрицательным результатом к общему числу тестов.
май июнь июль август сентябрь октябрь ноябрь декабрь
Месяц
■ Общее количество тестов ■ Количество тестов с отрицательными результатами
Рисунок 6: Отношение количества всех тестов с отрицательными результатами к общему числу тестов.
The ratio of the number of all failed tests to the total number of tests.
Более того, на Рисунке 7 представлен график количества часов, затраченных на выявление причин неудачных тестов в процессе применения контрактного тестирования.
Количество часов, затраченных на выявление причин неудачных тестов
май июнь июль август сентябрь октябрь ноябрь декабрь
Месяц
Рисунок 7: График количества часов, затраченных на выявление причин неудачных тестов.
A graph of the number of hours spent identifying the causes of failed tests.
Вышеупомянутый график демонстрирует, что благодаря внедрению контрактных тестов уровень упавших тестов значительно снижается, что в свою очередь приводит к сокращению времени, затрачиваемого на их исследование и устранение возникших проблем. Такое снижение времени, потраченного на выявление причин неудачных тестов, является ключевой составляющей успеха контрактного тестирования в обеспечении высокого уровня качества программного продукта и повышении эффективности работы разработчиков и тестировщиков.
Таким образом, в ходе работы над статьей была подробно обсуждена концепция контрактного тестирования, продемонстрированы его
ключевые принципы и преимущества. Показано, как контрактное тестирование способствует созданию единообразных и предсказуемых интерфейсов, облегчая интеграцию компонентов и упрощая поддержку. Также было продемонстрировано, как контрактное тестирование способно выявить возможные проблемы взаимодействия компонентов на ранних стадиях разработки, что позволяет проводить интеграционное тестирование, даже если реализация некоторых компонентов еще не завершена. Наглядно показано, что контрактное тестирование способствует быстрому обнаружению и исправлению ошибок, обеспечивая обнаружение нарушений контрактов и помогая идентифицировать причину проблемы.
Контрактное тестирование стало надежной защитой от непредвиденных изменений, обеспечивая контроль над взаимодействием с внешними сервисами и уверенность в правильной работе приложения в реальных условиях. Это позволило моей команде ускорить процесс разработки ПО, сократить время на поиск и устранение ошибок, а также повысить доверие к качеству продукта как для пользователей, так и для бизнес-партнеров. Стоит подчеркнуть, что контрактное тестирование упрощает командное взаимодействие и сотрудничество, становясь языком взаимодействия, который помогает установить и поддерживать согласованность и понимание между всеми участниками проекта. На основе успешного опыта применения контрактного тестирования, рекомендуется его использование другим командам разработки. Этот подход помогает создать более надежное, устойчивое и совместимое программное обеспечение, что является ключевым фактором в достижении бизнес-целей и обеспечении положительного опыта конечных пользователей.
СПИСОК ЛИТЕРАТУРЫ:
1. De Leo D, Zampivanea M. Contract-based testing for web service integrations: a systematic mapping study. 2018.
2. Wolfson. Building Microservices with Contract Testing. 2019.
3. Pact. Official Website. [cited 2023 Jul 31]. Available from: https://docs.pact.io
4. Pact. Official GitHub Repository. Documentation for Go programming language. [cited 2023 Jul 31]. Available from: https://github.com/pact-foundation/pact-go
5. HTTP-contract-testing Repository. [cited 2023 Jul 31]. Available from: https://github.com/disegmvm/HTTP-contract-testing
6. PactFlow. Official Website. [cited 2023 Jul 31]. Available from: https://pactflow.io/
7. Go. Official Documentation. [cited 2023 Jul 31]. Available from: https : //go. dev/doc/
8. Camunda. Seven Best Programming Languages for Microservices. [cited 2023 Jul 31]. Available from: https://camunda.com/blog/2022/09/seven-best-programming-languages-for-microservices
9. Pact. Official Docker Documentation. [cited 2023 Jul 31]. Available from: https : //docs.pact. io/docker
10. Dropbox. [cited 2023 Jul 31]. Available from: https://www.dropbox.com/
11. Google Drive. [cited 2023 Jul 31]. Available from: https://drive.google.com/
Peganov D.D.
Software Tester at TekHive CJSC (Torrevieja, Spain)
ACCELERATE DEVELOPMENT VIA CONTRACT TESTING WITH GO AND PACT
Abstract: accelerating development through contract testing with Go and Pact" is an expert article written by the author with the aim of researching and analyzing the complexities that arise during automated testing in the modern software world. In a situation where systems are becoming more complex and interact with each other and with many third-party services, testing approaches require deep understanding and innovative solutions. The author's main focus is on the concept of contract testing - an innovative approach based on the definition and verification of contracts between system components. This makes it possible to create uniform and predictable interfaces, identify potential problems of component interaction at early stages of development andfacilitate team interaction. The author analyzes and discusses in detail various aspects of contract testing, focusing on its role in detecting and eliminating errors, ensuring consistency and understanding between all project participants. The results of the study confirm the main assumptions and demonstrate the importance and effectiveness of contract testing in accelerating the software development process.
Keywords: GO language, application testing, software.
