Ilia Ushakov

Разделение тестов с помощью тегов сборки

2021-10-27T20:56:04.836Z

В Go есть внутренний механизм для логического разделения тестов в зависимости от некоторых условий, в том числе условий на операционную систему или тип CPU. Так, например, можно отделить юнит тесты от интеграционных или от smoke тестов.

Что такое теги сборки?

Тег сборки - это комментарий в начале go-файла, который указывает компилятору, как стоит собирать этот конкретный файл.

Например, при таком теге файл будет включен в сборку только в том случае, если компиляция выполняется под линукс (GOOS=linux)

// +build linux

package mypackage
...

Тег сборки должен быть расположен в начале файла, а после строки с ним должна быть пустая строка.

Также можно использовать оператор отрицания !. Таким образом, файл с тегом // +build !linux будет включен в сборку на всех платформах, кроме linux.

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

// +build linux darwin
// +build amd64

package mypackage
...

В примере выше файл будет включен в сборку только под linux/amd64 или darwin/amd64 платформы.

Разделение тестов

Через теги сборки можно разделять разные виды тестов.

Рассмотрим 2 файла тестов:
myfile_test.go:

package mypackage

import "testing"
...

myfile_integration_test.go:

// +build integration

package mypackage

import "testing"
...

В файле myfile_test.go будут расположены unit тесты, а в myfile_integration_test.go - интеграционные (более медленные).

Поэтому при запуске тестов через go test запустятся тесты только из myfile_test.go. А если нужно запустить тесты из myfile_integration_test.go, то надо добавить флаг —tags.

go test --tags=integration

Важно понимать, что при запуске go test --tags=integration так же запустятся unit тесты. Чтобы такого не произошло, надо добавить отрицание в теги сборки unit тестов.

myfile_test.go

// +build !integration

package mypackage

import "testing"
...

Итог

Есть несколько причин такого разделения тестов:

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

Источник: https://mickey.dev/posts/go-build-tags-testing/

Хранилище ceph

2021-09-19T11:19:23.121Z

Очень хорошая статья про хранилище ceph на хабре

Если коротко:

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

GOPROXY

2021-09-19T11:05:40.073Z

Начиная с версии Go 1.13, стандартный менеджер пакетов в Go - это Go modules. Вместе с ним появилась переменная окружения GOPROXY, которая определяет, откуда будут скачиваться пакеты.

Посмотреть текущую конфигурацию:

~ ❯ go env GOPROXY
https://proxy.golang.org,direct

В переменной GOPROXY будут указываться источники через запятую, откуда go будет пытаться скачать необходимый пакет. Если первый источник ответит 4xx, то go попробует скачать пакет по следующей ссылке.

Direct указывает, что код надо загрузить по прямой ссылке из VCS. То есть ровно по той ссылке, как пакет импортируется в коде.

Однако, загружать пакеты с VCS может быть не всегда безопасно.

Кто-то может внести вредоносный код в новых коммитах, или даже если вы строго зафиксировали версию пакета, с которым хотите работать, злоумышленник может изменить текущую версию кода через git push --force

Сейчас по умолчанию в GOPROXY устанавливается https://proxy.golang.org как прокси и работает как кеш. То есть если в proxy.golang.org нужного пакета не найдется, то он его скачает и сразу же отдаст нам. Этот кеш гарантирует, что код не будет изменен.

Источники:

https://golang.org/ref/mod#goproxy-protocol

https://jfrog.com/blog/why-goproxy-matters-and-which-to-pick/

Уровни логирования

2021-09-18T21:54:31.082Z

У логов следует использовать разные уровни, так будет легче фильтровать и исследовать проблему по логам.

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

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

Ниже описаны основные уровни логов и причины их использовать:

ERROR

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

Например: Внешний платежный шлюз перестал отвечать на наши запросы

WARNING

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

Например: На наш запрос не ответил внешний платежный шлюз. Дальше retry система попробует повторить запрос еще несколько раз. И если шлюз так и не ответит, то упадет ошибка ERROR

INFO

Произошло изменение в системе или в какой-то сущности.

Например:

1. Система поднялась на порту 8080

2. создан новый пользователь

3. вывод по cron задачу

DEBUG

Служит для отладки приложения при разработке, или в случае, когда надо поймать что-то на проде.

Например: текущее значение какой-то переменной

TRACE

Такой уровень логов нужен, чтобы отслеживать запросы внутри приложения.

Например:

Пришел запрос на url /home
Завершили обрабатывать запрос на /home за 0.5 секунд
Начали/завершили обрабатывать метод

Источник: https://reflectoring.io/logging-levels

Пишем unit тесты через сценарии

2021-09-18T20:11:47.377Z

При таком подходе тест состоит из 3х частей:

Состояние системы на момент запуска теста
Событие, которое изменяет состояние системы
Результат - то, что должно произойти/измениться

Для удобства предлагается разделить эти комментариями, чтобы не пытаться понять все через код.

Обратите внимание, что assert'ы выполняются только в третей части теста.

Названия тестовых методов является продолжением фразы: "Что случается, когда ..."

Источник: https://matthiasnoback.nl/2021/09/write-unit-tests-like-scenario

Собираем минимальный Docker образ для Golang приложений

2021-09-12T21:17:42.822Z

Обычный докер образ Golang приложения занимает порядка 600mb.

Чтобы облегчить образ, надо использовать multistage build. Это когда сначала все собирается в один образ, а потом результаты сборки копируются в другой. А инструменты сборки и все лишнее не копируются.

Так итоговый образ получился размером 4.3MB

hi

2021-09-05T18:54:28.739Z

$ git add articles/wizard-of-oz.txt
$ git commit -m 'wrote the wizard of oz.

jjjjj