Comments 6
Да да, автор имел ввиду именно 'четно', а никак не иначе. Благодарю всех за любопытство)
Хорошая статья для новичков!
Подскажите, а чем обусловлен выбор использования блоков кода + t.Log
вместо запуска под-тестов с помощью t.Run?
P.S.
Для дальнейшего чтения советую онлайн книгу Learn Go With Tests https://quii.gitbook.io/learn-go-with-tests/
А для красивого вывода результатов тестов рекомендую https://github.com/gotestyourself/gotestsum
![](https://habrastorage.org/getpro/habr/upload_files/d80/b7f/7fc/d80b7f7fc74e2a5a9b80296e15e3547f.gif)
Честно, не понял идеи вот такого написания тестов. В чём профит?
t.Log("Given the need to test TaxiDriver's behavior at different time.")
{
testID := 0
t.Logf("\tTest %d:\tWhen working in the morning.", testID)
{
...
}
Не проще ли писать так:
t.Run("foo", func(t *testing.T) {
t.Run("bar", func(t *testing.T) {
...
})
t.Run("fizz", func(t *testing.T) {
...
})
})
Из плюсов - можно запустить конкретный тест.
Какой-то уж очень громоздкий тест в конце получился и если не вчитываться, то не сразу поймёшь что к чему.
Мне кажется у вас имеется две большие проблемы:
Вы вначале написали код, а потом тест. Может TDD? В простом примере как у вас он был бы как нельзя кстати.
Отсутствие паттерна Arrange Act Assert. Если его применять, то тест становится более читаемым и структурированным
Рекомендую к прочтению книгу Принципы юнит тестирования https://habr.com/ru/company/piter/blog/528872/
"спустя четно потраченные нервы" - это звучит! )))) Вы сделали мой вечер!
Прагматичные Unit тесты на Golang