Последовательное выполнение пакетных тестов

Я реализовал несколько пакетов для веб-API, каждый из которых имеет свои собственные тестовые примеры. Когда каждый пакет тестируется с помощью go test ./api/pkgname, тесты проходят. Если я хочу запустить все тесты сразу с go test ./api/..., тестовые случаи всегда терпят неудачу.

В каждом тестовом случае я воссоздаю всю схему с помощью DROP SCHEMA public CASCADE, а затем CREATE SCHEMA public и применяю все миграции. В тестовом наборе сообщается об ошибках в случайном порядке, говоря, что отношения/таблицы не существует, поэтому я предполагаю, что каждый набор тестов (по каждому пакету) выполняется как-то параллельно, тем самым испортив состояние БД.

Я попытался пропустить несколько тестовых флагов, например go test -cpu 1 -parallel 0 ./src/api/..., без успеха.

Может ли проблема состоять в параллельном тестировании, и если да, то как я могу принудительно выполнить последовательный запуск?

Update:

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

find <dir> -type d -exec go test {} \;

Ответ 1

Как отмечали другие, -параллельный не выполняет работу (он работает только в пакетах). Тем не менее, вы можете использовать флаг -p = 1 для выполнения серийных тестов. Это описано здесь:

http://golang.org/src/cmd/go/testflag.go

но (afaict), а не в командной строке, обратитесь за помощью и т.д. Я не уверен, что он должен придерживаться (хотя я бы утверждал, что если он удален, - параллельный должен быть исправлен.)

Ответ 2

Инструмент go предназначен для облегчения проведения тестовых тестов с использованием соглашения, в котором файлы * _test.go содержат в них unittests. Поскольку он предполагает, что они являются unittests, он также предполагает, что они герметичны. Похоже, что ваши тесты не являются unittests или они только нарушают предположения, которые должен выполнить unittest.

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

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

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

Ответ 3

Просто, чтобы уточнить, ответ @Джереми все еще принят:

Поскольку мои интеграционные тесты выполнялись только на одном пакете (api), я удалил отдельный тестовый двоичный файл в конце и создал шаблон для разделения типов тестов с помощью:

В модульных тестах используется обычное TestX имя
В тестах интеграции используются Test_X

Я создал сценарии оболочки (utest.sh/itest.sh) для запуска любого из них.

Для модульных тестов go test -run="^(Test|Benchmark)[^_](.*)"
Для тестов интеграции go test -run"^(Test|Benchmark)_(.*)"
Запустите оба с помощью обычного go test