Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

11.04.2023

Підтести в Go з функцією T.Run

Сьогодні весь день писав тести на Go. Та, на сьомий рік написання тестів, нарешті дізнався про механізм створення підтестів: t.Run.

Нащо воно потрібно. Зазвичай в Go всі пишуть так звані матричні тести. Це коли всі параметри тесту та очікувані результати складаються в структуру, робиться масив таких структур, а потім цикл бігає по масиву та перевіряє код на кожному випадку. Для більш гнучкої мови програмування це може й дивно виглядало б, але на Go дуже зручно, бо копіпаста скорочується до мінімуму.

Я теж постійно використовую матричні тести. З ними є маленька проблемка: коли тест падає, то незрозуміло, в якому саме випадку. Тому я зазвичай до кожного очікування дописував повідомлення, по якому можна знайти випадок, якось так:

assert.Equal(t, e.expectedResult, myCode(e.param), e.name)

Та ще інша проблема: немає можливості запустити окремо один з випадків. Хіба що вдало закоментувати все зайве. От тільки в Go незручно коментувати шматки коду, бо компілятор почне журитися з невикористаних змінних.

Торік дізнався про існування пакета testify/suite. Їм можна загорнути набір тестів у спільний контекст, такий, як підключення до бази даних. Саме suite мене й наштовхнув на роздуми — а як це вони роблять тести у вкладеному форматі - Suite/TestName? Виявилось, що це вбудована можливість тестового середовища Go, називається підтести, та створюється функцією T.Run.

Підтести це те, чого мені не вистачало в матричних тестах, бо тепер достатньо просто загорнути тіло тесту в t.Run та отримати як підпис кожного підтесту в результатах, так і можливість фільтрувати їх ключем --run. А з пакетом testify/suite можна ще й додавати до підтестів контекст.

for _, e := range examples {
  t.Run(e.name, func(t *testing.T) {
    assert.Equal(t, e.expectedResult, myCode(e.param))
  })
}

Може, це й щось очевидне, але я загуглив пару топових туторіалів та вони матричні тести показують, а підтести — ні. Отакої. TIL.