Правильне іменування пакетів для тестування з мовою Go

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

Стратегія 1:

Ім'я файлу: github.com/user/myfunc.go

package myfunc

Назва тестового файлу: github.com/user/myfunc_test.go

package myfunc

Див . Приклад bzip2 .

Стратегія 2:

Ім'я файлу: github.com/user/myfunc.go

package myfunc

Назва тестового файлу: github.com/user/myfunc_test.go

package myfunc_test

import (
    "github.com/user/myfunc"
)

Дивіться приклад для дроту .

Стратегія 3:

Ім'я файлу: github.com/user/myfunc.go

package myfunc

Назва тестового файлу: github.com/user/myfunc_test.go

package myfunc_test

import (
    . "myfunc"
)

Див. Рядок для прикладу.

У стандартній бібліотеці Go, схоже, використовується суміш стратегій 1 і 2. Яку з усіх трьох слід використовувати? Це біль, що додається package *_testдо моїх пакетів тестування, оскільки це означає, що я не можу протестувати свої приватні методи пакету, але, можливо, є прихована перевага, про яку я не знаю?

Принципова різниця між трьома перерахованими вами стратегіями полягає в тому, чи є тестовий код в тому ж пакеті, що і тестований код. Рішення про використання package myfuncабо package myfunc_testв тестовому файлі залежить від того, чи хочете ви виконати тестування білого або чорного ящиків .

У використанні обох методів у проекті немає нічого поганого. Наприклад, ви могли б мати myfunc_whitebox_test.goі myfunx_blackbox_test.go.

Порівняння пакетів тестових кодів

• Тестування чорної скриньки: Використовуйте package myfunc_test, що забезпечить використання лише експортованих ідентифікаторів .
• Тестування білої скриньки: Використовуйте для package myfuncтого, щоб мати доступ до не експортованих ідентифікаторів. Підходить для модульних тестів, які вимагають доступу до не експортованих змінних, функцій та методів.

Порівняння стратегій, перелічених у питанні

• Стратегія 1: Файл myfunc_test.goвикористовує package myfunc- У цьому випадку тест - код в myfunc_test.goзнаходитиметься в тому ж пакеті, що і код тестованого в myfunc.go, що myfuncв цьому прикладі.
• Стратегія 2: Файл myfunc_test.goвикористовує package myfunc_test- у цьому випадку тестовий код у myfunc_test.go"буде скомпільований як окремий пакет, а потім зв'язаний і запущений з основним тестовим двійковим файлом". [Джерело: Рядки 58–59 у вихідному коді test.go ]
• Стратегія 3: файл myfunc_test.goвикористовує, package myfunc_testале імпортує, myfuncвикористовуючи позначення крапками - це варіант Стратегії 2, але використовує позначення крапками для імпорту myfunc.

Це залежить від обсягу ваших тестів. Тести високого рівня (інтеграція, прийняття тощо ...), можливо, слід помістити в окремий пакет, щоб переконатися, що ви використовуєте пакет через експортований API.

Якщо у вас є великий пакет з великою кількістю внутрішніх органів, які потрібно перевірити, використовуйте той самий пакет для своїх тестів. Але це не запрошення для ваших тестів отримати доступ до будь-якої частини приватного стану. Це зробило б рефакторинг кошмаром. Коли я пишу структури в go, я часто впроваджую інтерфейси. Це ті методи інтерфейсу, які я використовую у своїх тестах, а не всі допоміжні методи / функції окремо.

Вам слід використовувати стратегію 1, коли це можливо. Ви можете використовувати спеціальну foo_testназву пакета, щоб уникнути циклів імпорту, але це в основному є, тому стандартну бібліотеку можна протестувати за допомогою того ж механізму. Наприклад, stringsне можна перевірити за допомогою стратегії 1, оскільки testingпакет залежить від strings. Як ви вже сказали, у стратегії 2 або 3 у вас немає доступу до приватних ідентифікаторів пакету, тому зазвичай краще не використовувати його, якщо вам не потрібно.

Одні важливі примітки, про які я хотів би додати import .з Golang CodeReviewComments :

The import .Форма може бути корисна в тестах , які, з - за кругові залежності, не можуть бути зроблені частиною пакета тестуються:

package foo_test

import (
    "bar/testutil" // also imports "foo"
    . "foo"
)

У цьому випадку тестовий файл не може бути у пакунку foo, оскільки він використовує bar/testutil, що імпортує foo. Тому ми використовуємо "імпорт". форма, щоб файл міг видавати себе частиною пакета foo, навіть якщо це не так.

За винятком цього випадку, не використовуйтеimport . у своїх програмах. Це значно ускладнює читання програм, оскільки незрозуміло, чи є ім’я на кшталт Quux ідентифікатором верхнього рівня в поточному пакеті чи в імпортованому.