Пакет testing
Обзор
Пакет testing предоставляет поддержку автоматического тестирования пакетов Go. Он предназначен для использования совместно с командой «go test», которая автоматизирует выполнение функций вида
func TestXxx(*testing.T)
где Xxx не начинается с маленькой буквы. Имя функции служит для идентификации тестовой процедуры.
Внутри этих функций используйте методы Error, Fail или связанные с ними методы для сигнализации об ошибках.
Чтобы написать новый набор тестов, создайте файл, содержащий функции TestXxx, как описано здесь, и присвойте этому файлу имя, оканчивающееся на «_test.go». Файл будет исключён из обычных сборки пакетов, но будет включён при выполнении команды «go test».
Файл теста может находиться в том же пакете, что и тестируемый, или в соответствующем пакете с суффиксом «_test».
Если тестовый файл находится в том же пакете, он может ссылаться на неэкспортированные идентификаторы внутри пакета, как в этом примере:
package abs
import "testing"
func TestAbs(t *testing.T) {
got := Abs(-1)
if got != 1 {
t.Errorf("Abs(-1) = %d; want 1", got)
}
}
Если файл находится в отдельном пакете «_test», тестируемый пакет необходимо явно импортировать, и могут использоваться только его экспортированные идентификаторы. Это известно как тестирование «чёрного ящика».
package abs_test
import (
"testing"
"path_to_pkg/abs"
)
func TestAbs(t *testing.T) {
got := abs.Abs(-1)
if got != 1 {
t.Errorf("Abs(-1) = %d; want 1", got)
}
}
Для получения более подробной информации выполните «go help test» и «go help testflag».
Benchmarks
Функции вида
func BenchmarkXxx(*testing.B)
считаются бенчмарками и выполняются командой «go test», когда предоставляется флаг -bench. Бенчмарки выполняются последовательно.
Описание флагов тестирования см. в https://golang.org/cmd/go/#hdr-Testing_flags.
Пример функции бенчмарка выглядит так:
func BenchmarkRandInt(b *testing.B) {
for b.Loop() {
rand.Int()
}
}
Вывод
BenchmarkRandInt-8 68453040 17.8 ns/op
означает, что тело цикла выполнялось 68453040 раз со скоростью 17,8 нс за цикл.
Измеряется только тело цикла, поэтому бенчмарки могут выполнять дорогостоящую настройку перед вызовом b.Loop, которая не будет учитываться при измерении бенчмарка:
func BenchmarkBigLen(b *testing.B) {
big := NewBig()
for b.Loop() {
big.Len()
}
}
Если бенчмарку нужно протестировать производительность в параллельном режиме, он может использовать вспомогательную функцию RunParallel; такие бенчмарки предназначены для использования со флагом go test -cpu:
func BenchmarkTemplateParallel(b *testing.B) {
templ := template.Must(template.New("test").Parse("Hello, {{.}}!"))
b.RunParallel(func(pb *testing.PB) {
var buf bytes.Buffer
for pb.Next() {
buf.Reset()
templ.Execute(&buf, "World")
}
})
}
Подробное описание формата результатов бенчмарка приведено в https://golang.org/design/14313-benchmark-format.
Стандартные инструменты для работы с результатами бенчмарков находятся по адресу https://golang.org/x/perf/cmd. В частности, https://golang.org/x/perf/cmd/benchstat выполняет статистически надёжные сравнения A/B.
Бенчмарки типа b.N
До введения B.Loop, бенчмарки писались в другом стиле, используя B.N. Например:
func BenchmarkRandInt(b *testing.B) {
for range b.N {
rand.Int()
}
}
В этом стиле бенчмарка функция бенчмарка должна выполнять целевой код b.N раз. Функция бенчмарка вызывается несколько раз с корректировкой b.N, пока функция бенчмарка не продлится достаточно долго, чтобы её можно было надёжно измерить. Это также означает, что любая настройка, выполненная перед циклом, может быть выполнена несколько раз.
Если бенчмарку нужна какая-то дорогостоящая настройка перед запуском, таймер следует явно сбросить:
func BenchmarkBigLen(b *testing.B) {
big := NewBig()
b.ResetTimer()
for range b.N {
big.Len()
}
}
Новые бенчмарки должны предпочитать использование B.Loop, что более надёжно и эффективно.
Примеры
Пакет также запускает и проверяет примерный код. Функции примера могут включать заключительную строку комментария, начинающуюся с «Output:», и сравниваться со стандартным выводом функции при выполнении тестов. (Сравнение игнорирует начальные и конечные пробелы.) Это примеры примера:
func ExampleHello() {
fmt.Println("hello")
// Output: hello
}
func ExampleSalutations() {
fmt.Println("hello, and")
fmt.Println("goodbye")
// Output:
// hello, and
// goodbye
}
Префикс комментария «Unordered output:» похож на «Output:», но соответствует любому порядку строк:
func ExamplePerm() {
for _, value := range Perm(5) {
fmt.Println(value)
}
// Unordered output: 4
// 2
// 1
// 3
// 0
}
Функции примера без комментариев вывода компилируются, но не выполняются.
Конвенция именования для объявления примеров для пакета, функции F, типа T и метода M типа T:
func Example() { ... }
func ExampleF() { ... }
func ExampleT() { ... }
func ExampleT_M() { ... }
Несколько функций примера для пакета/типа/функции/метода могут быть предоставлены путём добавления отличительного суффикса к имени. Суффикс должен начинаться с маленькой буквы.
func Example_suffix() { ... }
func ExampleF_suffix() { ... }
func ExampleT_suffix() { ... }
func ExampleT_M_suffix() { ... }
Весь тестовый файл представляется как пример, когда он содержит единственную функцию примера, по крайней мере одну другую функцию, тип, переменную или объявление константы и не содержит функций тестов или бенчмарков.
Fuzzing
«go test» и пакет testing поддерживают fuzzing — технику тестирования, в которой функция вызывается с произвольно сгенерированными входными данными для поиска ошибок, не предвиденных unit-тестами.
Функции вида
func FuzzXxx(*testing.F)
считаются fuzz-тестами.
Например:
func FuzzHex(f *testing.F) {
for _, seed := range [][]byte{{}, {0}, {9}, {0xa}, {0xf}, {1, 2, 3, 4}} {
f.Add(seed)
}
f.Fuzz(func(t *testing.T, in []byte) {
enc := hex.EncodeToString(in)
out, err := hex.DecodeString(enc)
if err != nil {
t.Fatalf("%v: decode: %v", in, err)
}
if !bytes.Equal(in, out) {
t.Fatalf("%v: not equal after round trip: %v", in, out)
}
})
}
Fuzz-тест поддерживает corpus семян, или набор входных данных, который по умолчанию выполняется и может генерировать ввод семян. Семена ввода могут быть зарегистрированы путём вызова (*F).Add или путём хранения файлов в каталоге testdata/fuzz/<Name> (где <Name> — имя fuzz-теста) внутри пакета, содержащего fuzz-тест. Семена ввода необязательны, но движок fuzzing может находить ошибки более эффективно, если ему предоставлен набор небольших семян ввода с хорошим покрытием кода. Эти семена ввода также могут служить регрессионными тестами для ошибок, выявленных путём fuzzing.
Функция, переданная (*F).Fuzz в рамках fuzz-теста, считается fuzz-целью. Fuzz-цель должна принимать параметр *T, за которым следуют один или несколько параметров для случайных входных данных. Типы аргументов, передаваемых (*F).Add, должны быть идентичны типам этих параметров. Fuzz-цель может сигнализировать о том, что она нашла проблему, так же как и тесты: вызывая T.Fail (или любой метод, вызывающий его, например, T.Error или T.Fatal), или путём возникновения паники.
При включенном fuzzing (установкой флага -fuzz на регулярное выражение, соответствующее определённому fuzz-тесту), fuzz-цель вызывается с аргументами, генерируемыми путём многократного внесения случайных изменений в семена ввода. На поддерживаемых платформах «go test» компилирует исполняемый файл теста с instrumentaцией покрытия fuzzing. Движок fuzzing использует эту instrumentaцию для поиска и кэширования входных данных, которые расширяют покрытие, увеличивая вероятность обнаружения ошибок. Если fuzz-цель терпит неудачу для данного входного значения, движок fuzzing записывает входные данные, которые привели к ошибке, в файл в каталоге testdata/fuzz/<Name> внутри каталога пакета. Этот файл впоследствии служит семенем ввода. Если файл не может быть записан в этом месте (например, потому что каталог только для чтения), движок fuzzing записывает файл в каталог кэша fuzz внутри кэша сборки.
При отключенном fuzzing fuzz-цель вызывается с семенами ввода, зарегистрированными с F.Add, и семенами ввода из testdata/fuzz/<Name>. В этом режиме fuzz-тест ведет себя как обычный тест, с подтестами, запущенными с F.Fuzz вместо T.Run.
См. https://go.dev/doc/fuzz для документации по fuzzing.
Пропуск
Тесты или бенчмарки могут быть пропущены во время выполнения с помощью вызова метода Skip для *T или *B:
func TestTimeConsuming(t *testing.T) {
if testing.Short() {
t.Skip("skipping test in short mode.")
}
...
}
Метод Skip для *T может быть использован в fuzz-цели, если вход недействителен, но не должен рассматриваться как неудачный ввод. Например:
func FuzzJSONMarshaling(f *testing.F) {
f.Fuzz(func(t *testing.T, b []byte) {
var v interface{}
if err := json.Unmarshal(b, &v); err != nil {
t.Skip()
}
if _, err := json.Marshal(v); err != nil {
t.Errorf("Marshal: %v", err)
}
})
}
Подтесты и под-бенчмарки
Методы Run для T и B позволяют определять подтесты и под-бенчмарки, не определяя отдельные функции для каждого. Это позволяет использовать табличное определение бенчмарков и создавать иерархические тесты. Это также предоставляет способ совместного использования общего кода настройки и разборки:
func TestFoo(t *testing.T) {
// <setup code>
t.Run("A=1", func(t *testing.T) { ... })
t.Run("A=2", func(t *testing.T) { ... })
t.Run("B=1", func(t *testing.T) { ... })
// <tear-down code>
}
Каждый подтест и под-бенчмарк имеет уникальное имя: комбинацию имени верхнего уровня теста и последовательности имён, переданных Run, разделённых слэшами, с необязательным завершающим порядковым номером для устранения неоднозначности.
Аргумент для флагов командной строки -run, -bench и -fuzz — это регулярное выражение без якорей, которое соответствует имени теста. Для тестов с несколькими элементами, разделёнными слэшами, такими как подтесты, аргумент сам по себе разделяется слэшами, с выражениями, соответствующими каждому элементу имени по очереди. Поскольку он не является якорем, пустое выражение соответствует любой строке. Например, используя «соответствие», чтобы означать «чей адрес содержит»:
go test -run '' # Run all tests. go test -run Foo # Run top-level tests matching "Foo", such as "TestFooBar". go test -run Foo/A= # For top-level tests matching "Foo", run subtests matching "A=". go test -run /A=1 # For all top-level tests, run subtests matching "A=1". go test -fuzz FuzzFoo # Fuzz the target matching "FuzzFoo"
Аргумент -run также может использоваться для запуска определённого значения в корпусе семян для отладки. Например:
go test -run=FuzzFoo/9ddb952d9814
Флаги -fuzz и -run могут быть установлены одновременно, чтобы запустить fuzzing целевого объекта, но пропустить выполнение всех остальных тестов.
Подтесты также могут использоваться для управления параллелизмом. Родительский тест завершит свою работу только после завершения всех его подтестов. В этом примере все тесты выполняются параллельно друг с другом, и только друг с другом, независимо от других тестов верхнего уровня, которые могут быть определены:
func TestGroupedParallel(t *testing.T) {
for _, tc := range tests {
tc := tc // capture range variable
t.Run(tc.Name, func(t *testing.T) {
t.Parallel()
...
})
}
}
Run не возвращает результат до тех пор, пока не завершатся подтесты, работающие параллельно, что предоставляет способ очистки после группы параллельных тестов:
func TestTeardownParallel(t *testing.T) {
// This Run will not return until the parallel tests finish.
t.Run("group", func(t *testing.T) {
t.Run("Test1", parallelTest1)
t.Run("Test2", parallelTest2)
t.Run("Test3", parallelTest3)
})
// <tear-down code>
}
Main
Иногда требуется, чтобы программа теста или бенчмарка выполняла дополнительную настройку или разборку перед или после выполнения. Иногда также необходимо управлять тем, какой код выполняется в главном потоке. Для поддержки этих и других случаев, если тестовый файл содержит функцию:
func TestMain(m *testing.M)
то сгенерированный тест вызовет TestMain(m) вместо непосредственного запуска тестов или бенчмарков. TestMain выполняется в главном горутине и может выполнять любую необходимую настройку и разборку вокруг вызова m.Run. m.Run вернёт код выхода, который можно передать в os.Exit. Если TestMain возвращает значение, обёртка теста передаст результат m.Run в os.Exit.
При вызове TestMain флаг flag.Parse ещё не был выполнен. Если TestMain зависит от флагов командной строки, включая флаги пакета testing, он должен явно вызвать flag.Parse. Флаги командной строки всегда парсятся к моменту выполнения функций теста или бенчмарка.
Простой пример TestMain:
func TestMain(m *testing.M) {
// call flag.Parse() here if TestMain uses flags
m.Run()
}
TestMain — это низкоуровневый примитив и не должен быть необходим для случайных потребностей в тестировании, где обычные функции тестов достаточны.
Индекс
Файлы пакета
allocs.go benchmark.go cover.go example.go fuzz.go match.go newcover.go run_example.go testing.go testing_other.go
func AllocsPerRun 1.1
func AllocsPerRun(runs int, f func()) (avg float64)
AllocsPerRun возвращает среднее число выделений памяти во время вызовов f. Несмотря на то, что возвращаемое значение имеет тип float64, оно всегда будет целочисленным.
Для вычисления количества выделений функция сначала выполняется один раз для разогрева. Затем измеряется среднее количество выделений за указанное количество запусков и возвращается.
AllocsPerRun устанавливает GOMAXPROCS в 1 во время измерения и восстанавливает его перед возвратом.
func CoverMode 1.8
func CoverMode() string
CoverMode сообщает, какое значение установлено для режима покрытия кода. Значения — "set", "count" или "atomic". Возвращаемое значение будет пустым, если покрытие кода не включено.
func Coverage 1.4
func Coverage() float64
Coverage сообщает о текущем покрытии кода как о дроби в диапазоне [0, 1]. Если покрытие кода не включено, Coverage возвращает 0.
При выполнении большого набора последовательных тестовых случаев проверка Coverage после каждого из них может быть полезна для выявления тестовых случаев, которые охватывают новые пути кода. Это не заменяет отчеты, генерируемые командами 'go test -cover' и 'go tool cover'.
func Init 1.13
func Init()
Init регистрирует флаги тестирования. Эти флаги автоматически регистрируются командой "go test" перед запуском тестовых функций, поэтому Init требуется только при вызове функций, таких как Benchmark, без использования "go test".
Init нельзя вызывать параллельно. Он не имеет эффекта, если уже был вызван.
func Main
func Main(matchString func(pat, str string) (bool, error), tests []InternalTest, benchmarks []InternalBenchmark, examples []InternalExample)
Main — внутренняя функция, часть реализации команды "go test". Она была экспортирована, потому что является межпакетной и предшествует пакетам "internal". Она больше не используется командой "go test", но сохранена, насколько это возможно, для других систем, которые имитируют "go test" с помощью Main, но Main иногда не может быть обновлена, поскольку в пакет тестирования добавляется новая функциональность. Системы, имитирующие "go test", должны быть обновлены для использования MainStart.
func RegisterCover 1.2
func RegisterCover(c Cover)
RegisterCover записывает накопители данных покрытия кода для тестов. ПРИМЕЧАНИЕ: Эта функция является внутренней частью инфраструктуры тестирования и может быть изменена. Она пока не покрывается руководством по совместимости Go 1.
func RunBenchmarks
func RunBenchmarks(matchString func(pat, str string) (bool, error), benchmarks []InternalBenchmark)
RunBenchmarks — внутренняя функция, но экспортирована, потому что является межпакетной; она является частью реализации команды "go test".
func RunExamples
func RunExamples(matchString func(pat, str string) (bool, error), examples []InternalExample) (ok bool)
RunExamples — внутренняя функция, но экспортирована, потому что является межпакетной; она является частью реализации команды "go test".
func RunTests
func RunTests(matchString func(pat, str string) (bool, error), tests []InternalTest) (ok bool)
RunTests — внутренняя функция, но экспортирована, потому что является межпакетной; она является частью реализации команды "go test".
func Short
func Short() bool
Short сообщает, установлено ли значение флага -test.short.
func Testing 1.21
func Testing() bool
Отчеты об испытаниях проверяют, выполняется ли текущий код в режиме тестирования. Это будет сообщать true в программах, созданных с помощью «go test», и false в программах, созданных с помощью «go build».
func Verbose 1.1
func Verbose() bool
Verbose сообщает, установлен ли флаг -test.v.
type B
B — тип, передаваемый в функции Benchmark для управления временем выполнения бенчмарка и контролем числа итераций.
Бенчмарк завершается, когда его функция Benchmark возвращается или вызывает любую из методов FailNow, Fatal, Fatalf, SkipNow, Skip или Skipf. Эти методы должны вызываться только из потока, в котором выполняется функция Benchmark. Другие методы отчётности, такие как варианты Log и Error, могут быть вызваны одновременно из нескольких потоков.
Как и в тестах, журналы бенчмарков накапливаются во время выполнения и выводятся в стандартный вывод по окончании. В отличие от тестов, журналы бенчмарков всегда выводятся, чтобы не скрывать вывод, существование которого может влиять на результаты бенчмарков.
type B struct {
N int
// contains filtered or unexported fields
}
func (*B) Chdir 1.24
func (c *B) Chdir(dir string)
Chdir вызывает os.Chdir(dir) и использует Cleanup для восстановления текущей рабочей директории до её первоначального значения после завершения теста. В Unix также устанавливается переменная окружения PWD на время теста.
Поскольку Chdir влияет на весь процесс, его нельзя использовать в параллельных тестах или тестах с параллельными предками.
func (*B) Cleanup 1.14
func (c *B) Cleanup(f func())
Cleanup регистрирует функцию, которая должна быть вызвана при завершении теста (или подтеста) и всех его подтестов. Функции Cleanup будут вызваны в порядке, обратном порядку добавления.
func (*B) Context 1.24
func (c *B) Context() context.Context
Context возвращает контекст, который отменяется незадолго до вызова функций, зарегистрированных с помощью Cleanup.
Функции Cleanup могут ожидать любых ресурсов, которые закрываются при вызове Context.Done, прежде чем тест или бенчмарк завершатся.
func (*B) Elapsed 1.20
func (b *B) Elapsed() time.Duration
Elapsed возвращает измеренное время выполнения бенчмарка. Длительность, возвращаемая Elapsed, соответствует той, что измеряется с помощью B.StartTimer, B.StopTimer и B.ResetTimer.
func (*B) Error
func (c *B) Error(args ...any)
Error эквивалентен Log, за которым следует Fail.
func (*B) Errorf
func (c *B) Errorf(format string, args ...any)
Errorf эквивалентен Logf, за которым следует Fail.
func (*B) Fail
func (c *B) Fail()
Fail помечает функцию как завершившуюся с ошибкой, но продолжает выполнение.
func (*B) FailNow
func (c *B) FailNow()
FailNow помечает функцию как завершившуюся с ошибкой и останавливает её выполнение, вызывая runtime.Goexit (который затем выполняет все отложенные вызовы в текущем потоке). Выполнение продолжится в следующем тесте или бенчмарке. FailNow должен вызываться из потока, в котором выполняется функция теста или бенчмарка, а не из других потоков, созданных во время теста. Вызов FailNow не останавливает эти другие потоки.
func (*B) Failed
func (c *B) Failed() bool
Failed сообщает, завершилась ли функция с ошибкой.
func (*B) Fatal
func (c *B) Fatal(args ...any)
Fatal эквивалентен Log, за которым следует FailNow.
func (*B) Fatalf
func (c *B) Fatalf(format string, args ...any)
Fatalf эквивалентен Logf, за которым следует FailNow.
func (*B) Helper 1.9
func (c *B) Helper()
Helper помечает вызывающую функцию как функцию-помощник для тестов. При выводе информации о файле и строке эта функция будет пропущена. Helper может вызываться одновременно из нескольких потоков.
func (*B) Log
func (c *B) Log(args ...any)
Log форматирует свои аргументы с помощью стандартного форматирования, аналогично Println, и записывает текст в журнал ошибок. Для тестов текст будет выведен только в случае ошибки в тесте или если установлен флаг -test.v. Для бенчмарков текст всегда выводится, чтобы избежать зависимости производительности от значения флага -test.v.
func (*B) Logf
func (c *B) Logf(format string, args ...any)
Logf форматирует свои аргументы в соответствии с форматом, аналогично Printf, и записывает текст в журнал ошибок. В конце добавляется перевод строки, если он не был указан. Для тестов текст будет выведен только в случае ошибки в тесте или если установлен флаг -test.v. Для бенчмарков текст всегда выводится, чтобы избежать зависимости производительности от значения флага -test.v.
func (*B) Loop 1.24
func (b *B) Loop() bool
Loop возвращает true, пока бенчмарк должен продолжать выполняться.
Типичная структура бенчмарка:
func Benchmark(b *testing.B) {
... setup ...
for b.Loop() {
... code to measure ...
}
... cleanup ...
}
Loop сбрасывает таймер бенчмарка при первом вызове в бенчмарке, поэтому любая настройка, выполненная до начала цикла бенчмарка, не учитывается при измерении бенчмарка. Аналогично, при возвращении false, таймер останавливается, поэтому код очистки не измеряется.
Компилятор никогда не оптимизирует вызовы функций внутри тела цикла «for b.Loop() { ... }». Это предотвращает неожиданности, которые могут возникнуть, если компилятор определит, что результат функции бенчмарка не используется. Цикл должен быть написан именно в этом формате, и это относится только к вызовам синтаксически между фигурными скобками цикла. Оптимизация выполняется как обычно для любых функций, вызываемых циклом.
После того как Loop возвращает false, b.N содержит общее число итераций, которые были выполнены, поэтому бенчмарк может использовать b.N для вычисления других метрик среднего значения.
Перед введением Loop ожидалось, что бенчмарки будут содержать явный цикл от 0 до b.N. Бенчмарки должны использовать Loop или содержать цикл до b.N, но не то и другое одновременно. Loop обеспечивает более автоматическое управление таймером бенчмарка и выполняет каждую функцию бенчмарка только один раз за измерение, в то время как бенчмарки на основе b.N должны выполнять функцию бенчмарка (и любые связанные настройки и очистку) несколько раз.
Пример
Код:
package testing_test
import (
"math/rand/v2"
"testing"
)
// ExBenchmark shows how to use b.Loop in a benchmark.
//
// (If this were a real benchmark, not an example, this would be named
// BenchmarkSomething.)
func ExBenchmark(b *testing.B) {
// Generate a large random slice to use as an input.
// Since this is done before the first call to b.Loop(),
// it doesn't count toward the benchmark time.
input := make([]int, 128<<10)
for i := range input {
input[i] = rand.Int()
}
// Perform the benchmark.
for b.Loop() {
// Normally, the compiler would be allowed to optimize away the call
// to sum because it has no side effects and the result isn't used.
// However, inside a b.Loop loop, the compiler ensures function calls
// aren't optimized away.
sum(input)
}
// Outside the loop, the timer is stopped, so we could perform
// cleanup if necessary without affecting the result.
}
func sum(data []int) int {
total := 0
for _, value := range data {
total += value
}
return total
}
func ExampleB_Loop() {
testing.Benchmark(ExBenchmark)
}
func (*B) Name 1.8
func (c *B) Name() string
Name возвращает имя выполняемого (под-)теста или бенчмарка.
Имя будет включать имя теста вместе с именами любых вложенных подтестов. Если у двух подтестов-братьев одинаковое имя, Name добавит суффикс, чтобы гарантировать, что возвращаемое имя уникально.
func (*B) ReportAllocs 1.1
func (b *B) ReportAllocs()
ReportAllocs включает статистику malloc для этого бенчмарка. Это эквивалентно установке -test.benchmem, но это влияет только на функцию бенчмарка, которая вызывает ReportAllocs.
func (*B) ReportMetric 1.13
func (b *B) ReportMetric(n float64, unit string)
ReportMetric добавляет «n unit» к отчёту о результатах бенчмарка. Если метрика на итерацию, вызывающий должен разделить на b.N, а по соглашению единицы должны оканчиваться на «/op». ReportMetric перезаписывает любое ранее отчётное значение для той же единицы. ReportMetric вызывает панику, если unit — пустая строка или содержит пробелы. Если unit — единица, обычно отчитываемая фреймворком бенчмарка (например, «allocs/op»), ReportMetric переопределит эту метрику. Установка «ns/op» в 0 подавит эту встроенную метрику.
Пример
Код:
// This reports a custom benchmark metric relevant to a
// specific algorithm (in this case, sorting).
testing.Benchmark(func(b *testing.B) {
var compares int64
for b.Loop() {
s := []int{5, 4, 3, 2, 1}
slices.SortFunc(s, func(a, b int) int {
compares++
return cmp.Compare(a, b)
})
}
// This metric is per-operation, so divide by b.N and
// report it as a "/op" unit.
b.ReportMetric(float64(compares)/float64(b.N), "compares/op")
// This metric is per-time, so divide by b.Elapsed and
// report it as a "/ns" unit.
b.ReportMetric(float64(compares)/float64(b.Elapsed().Nanoseconds()), "compares/ns")
})
Пример (параллельный)
Код:
// This reports a custom benchmark metric relevant to a
// specific algorithm (in this case, sorting) in parallel.
testing.Benchmark(func(b *testing.B) {
var compares atomic.Int64
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
s := []int{5, 4, 3, 2, 1}
slices.SortFunc(s, func(a, b int) int {
// Because RunParallel runs the function many
// times in parallel, we must increment the
// counter atomically to avoid racing writes.
compares.Add(1)
return cmp.Compare(a, b)
})
}
})
// NOTE: Report each metric once, after all of the parallel
// calls have completed.
// This metric is per-operation, so divide by b.N and
// report it as a "/op" unit.
b.ReportMetric(float64(compares.Load())/float64(b.N), "compares/op")
// This metric is per-time, so divide by b.Elapsed and
// report it as a "/ns" unit.
b.ReportMetric(float64(compares.Load())/float64(b.Elapsed().Nanoseconds()), "compares/ns")
})
func (*B) ResetTimer
func (b *B) ResetTimer()
ResetTimer обнуляет измеренное время бенчмарка и счётчики выделения памяти, а также удаляет отчётные метрики пользователя. Он не влияет на то, запущен ли таймер.
func (*B) Run 1.7
func (b *B) Run(name string, f func(b *B)) bool
Run запускает бенчмарки f как подбенчмарки с заданным именем. Сообщает, были ли какие-либо ошибки.
Подбенчмарк похож на любой другой бенчмарк. Бенчмарк, который хотя бы один раз вызывает Run, сам не будет измеряться и будет вызван один раз с N=1.
func (*B) RunParallel 1.3
func (b *B) RunParallel(body func(*PB))
RunParallel запускает бенчмарк параллельно. Создаёт несколько потоков и распределяет b.N итераций между ними. Количество потоков по умолчанию равно GOMAXPROCS. Чтобы увеличить параллельность для не зависящих от процессора бенчмарков, вызовите B.SetParallelism перед RunParallel. RunParallel обычно используется с флагом go test -cpu.
Функция тела будет выполняться в каждом потоке. Она должна настроить любые локальные для потока состояния, а затем итерировать до тех пор, пока pb.Next не вернёт false. Она не должна использовать функции B.StartTimer, B.StopTimer или B.ResetTimer, потому что они имеют глобальное влияние. Она также не должна вызывать B.Run.
RunParallel отчитывает значения ns/op как время выполнения для всего бенчмарка, а не сумму времени выполнения или времени процессора в каждом параллельном потоке.
Пример
Код:
// Parallel benchmark for text/template.Template.Execute on a single object.
testing.Benchmark(func(b *testing.B) {
templ := template.Must(template.New("test").Parse("Hello, {{.}}!"))
// RunParallel will create GOMAXPROCS goroutines
// and distribute work among them.
b.RunParallel(func(pb *testing.PB) {
// Each goroutine has its own bytes.Buffer.
var buf bytes.Buffer
for pb.Next() {
// The loop body is executed b.N times total across all goroutines.
buf.Reset()
templ.Execute(&buf, "World")
}
})
})
func (*B) SetBytes
func (b *B) SetBytes(n int64)
SetBytes записывает количество байтов, обработанных за одну операцию. Если это вызвано, бенчмарк будет отчитываться о ns/op и MB/s.
func (*B) SetParallelism 1.3
func (b *B) SetParallelism(p int)
SetParallelism устанавливает количество потоков, используемых B.RunParallel, в p*GOMAXPROCS. Для бенчмарков, зависящих от процессора, обычно нет необходимости вызывать SetParallelism. Если p меньше 1, этот вызов не будет иметь эффекта.
func (*B) Setenv 1.17
func (c *B) Setenv(key, value string)
Setenv вызывает os.Setenv(key, value) и использует Cleanup для восстановления переменной окружения до её первоначального значения после теста.
Поскольку Setenv влияет на весь процесс, его нельзя использовать в параллельных тестах или тестах с параллельными предками.
func (*B) Skip 1.1
func (c *B) Skip(args ...any)
Skip эквивалентен Log, за которым следует SkipNow.
func (*B) SkipNow 1.1
func (c *B) SkipNow()
SkipNow помечает тест как пропущенный и останавливает его выполнение, вызывая runtime.Goexit. Если тест завершается ошибкой (см. Error, Errorf, Fail) и затем пропускается, он всё равно считается завершившимся с ошибкой. Выполнение продолжится в следующем тесте или бенчмарке. См. также FailNow. SkipNow должен вызываться из потока, в котором выполняется тест, а не из других потоков, созданных во время теста. Вызов SkipNow не останавливает эти другие потоки.
func (*B) Skipf 1.1
func (c *B) Skipf(format string, args ...any)
Skipf эквивалентен Logf, за которым следует SkipNow.
func (*B) Skipped 1.1
func (c *B) Skipped() bool
Skipped сообщает, пропущен ли тест.
func (*B) StartTimer
func (b *B) StartTimer()
StartTimer запускает таймер теста. Эта функция вызывается автоматически перед началом бенчмарка, но также может использоваться для возобновления таймера после вызова B.StopTimer.
func (*B) StopTimer
func (b *B) StopTimer()
StopTimer останавливает таймер теста. Это можно использовать для приостановки таймера во время выполнения шагов, которые не нужно измерять.
func (*B) TempDir 1.15
func (c *B) TempDir() string
TempDir возвращает временную директорию для использования тестом. Директория автоматически удаляется после завершения теста и всех его подтестов. Каждый последующий вызов t.TempDir возвращает уникальную директорию; если создание директории завершается ошибкой, TempDir завершает тест, вызвав Fatal.
type BenchmarkResult
BenchmarkResult содержит результаты выполнения бенчмарка.
type BenchmarkResult struct {
N int // The number of iterations.
T time.Duration // The total time taken.
Bytes int64 // Bytes processed in one iteration.
MemAllocs uint64 // The total number of memory allocations; added in Go 1.1
MemBytes uint64 // The total number of bytes allocated; added in Go 1.1
// Extra records additional metrics reported by ReportMetric.
Extra map[string]float64 // Go 1.13
}
func Benchmark
func Benchmark(f func(b *B)) BenchmarkResult
Benchmark проводит бенчмарк одной функции. Это полезно для создания пользовательских бенчмарков, которые не используют команду "go test".
Если f зависит от флагов тестирования, то Init должен быть использован для регистрации этих флагов перед вызовом Benchmark и перед вызовом flag.Parse.
Если f вызывает Run, результат будет оценкой запуска всех его подбенчмарков, которые не вызывают Run последовательно, в одном бенчмарке.
func (BenchmarkResult) AllocedBytesPerOp 1.1
func (r BenchmarkResult) AllocedBytesPerOp() int64
AllocedBytesPerOp возвращает метрику "B/op", которая рассчитывается как r.MemBytes / r.N.
func (BenchmarkResult) AllocsPerOp 1.1
func (r BenchmarkResult) AllocsPerOp() int64
AllocsPerOp возвращает метрику "allocs/op", которая рассчитывается как r.MemAllocs / r.N.
func (BenchmarkResult) MemString 1.1
func (r BenchmarkResult) MemString() string
MemString возвращает r.AllocedBytesPerOp и r.AllocsPerOp в том же формате, что и 'go test'.
func (BenchmarkResult) NsPerOp
func (r BenchmarkResult) NsPerOp() int64
NsPerOp возвращает метрику "ns/op".
func (BenchmarkResult) String
func (r BenchmarkResult) String() string
String возвращает сводку результатов бенчмарка. Она следует формату строки результатов бенчмарка из https://golang.org/design/14313-benchmark-format, не включая имя бенчмарка. Дополнительные метрики перезаписывают встроенные метрики с тем же именем. String не включает allocs/op или B/op, так как они отображаются в BenchmarkResult.MemString.
type Cover 1.2
Cover записывает информацию о проверке покрытия тестов. ПРИМЕЧАНИЕ: Эта структура является внутренней для инфраструктуры тестирования и может измениться. Она пока не покрывается руководством по совместимости Go 1.
type Cover struct {
Mode string
Counters map[string][]uint32
Blocks map[string][]CoverBlock
CoveredPackages string
}
type CoverBlock 1.2
CoverBlock записывает данные о покрытии для одного базового блока. Поля индексируются с 1, как в редакторе: первая строка файла имеет номер 1, например. Столбцы измеряются в байтах. ПРИМЕЧАНИЕ: Эта структура является внутренней для инфраструктуры тестирования и может измениться. Она пока не покрывается руководством по совместимости Go 1.
type CoverBlock struct {
Line0 uint32 // Line number for block start.
Col0 uint16 // Column number for block start.
Line1 uint32 // Line number for block end.
Col1 uint16 // Column number for block end.
Stmts uint16 // Number of statements included in this block.
}
type F 1.18
F — тип, передаваемый тестам на fuzz.
Тесты fuzz запускают сгенерированные входные данные против заданного целевого fuzz, чтобы найти и сообщить о потенциальных ошибках в тестируемом коде.
По умолчанию тест fuzz запускает начальный набор входных данных (seed corpus), который включает записи, предоставленные (*F).Add, и записи в директории testdata/fuzz/<FuzzTestName>. После всех необходимых настроек и вызовов (*F).Add тест fuzz должен вызвать (*F).Fuzz для задания fuzz-цели. См. документацию пакета testing для примера, и см. документацию метода F.Fuzz и F.Add для подробностей.
Методы *F могут быть вызваны только до (*F).Fuzz. После запуска теста fuzz-цели можно использовать только методы (*T). Единственные методы *F, разрешенные в функции (*F).Fuzz, это (*F).Failed и (*F).Name.
type F struct {
// contains filtered or unexported fields
}
func (*F) Add 1.18
func (f *F) Add(args ...any)
Add добавит аргументы в seed corpus для fuzz-теста. Это будет ничто, если вызвано после или внутри fuzz-цели, и аргументы должны соответствовать аргументам для fuzz-цели.
func (*F) Chdir 1.24
func (c *F) Chdir(dir string)
Chdir вызывает os.Chdir(dir) и использует Cleanup для восстановления текущей рабочей директории до ее исходного значения после завершения теста. В Unix также устанавливает переменную среды PWD на время теста.
Поскольку Chdir влияет на весь процесс, его нельзя использовать в параллельных тестах или тестах с параллельными предками.
func (*F) Cleanup 1.18
func (c *F) Cleanup(f func())
Cleanup регистрирует функцию, которая будет вызвана при завершении теста (или подтеста) и всех его подтестов. Функции Cleanup будут вызваны в порядке, в котором они были добавлены последними, первой вызывается.
func (*F) Context 1.24
func (c *F) Context() context.Context
Context возвращает контекст, который отменяется непосредственно перед вызовом функций, зарегистрированных в Cleanup.
Функции Cleanup могут ожидать завершения любых ресурсов, которые завершают работу в Context.Done перед завершением теста или бенчмарка.
func (*F) Error 1.18
func (c *F) Error(args ...any)
Error эквивалентен Log, за которым следует Fail.
func (*F) Errorf 1.18
func (c *F) Errorf(format string, args ...any)
Errorf эквивалентен Logf, за которым следует Fail.
func (*F) Fail 1.18
func (f *F) Fail()
Fail помечает функцию как завершившуюся с ошибкой, но продолжает выполнение.
func (*F) FailNow 1.18
func (c *F) FailNow()
FailNow помечает функцию как завершившуюся с ошибкой и останавливает ее выполнение, вызвав runtime.Goexit (который затем выполняет все отложенные вызовы в текущей горутине). Выполнение продолжится в следующем тесте или бенчмарке. FailNow должен быть вызван из горутины, выполняющей функцию теста или бенчмарка, а не из других горутин, созданных во время теста. Вызов FailNow не останавливает эти другие горутины.
func (*F) Failed 1.18
func (c *F) Failed() bool
Failed сообщает, завершилась ли функция с ошибкой.
func (*F) Fatal 1.18
func (c *F) Fatal(args ...any)
Fatal эквивалентен Log, за которым следует FailNow.
func (*F) Fatalf 1.18
func (c *F) Fatalf(format string, args ...any)
Fatalf эквивалентен Logf, за которым следует FailNow.
func (*F) Fuzz 1.18
func (f *F) Fuzz(ff any)
Fuzz запускает функцию fuzz, ff, для тестирования fuzz. Если ff завершается ошибкой для набора аргументов, эти аргументы будут добавлены в seed corpus.
ff должна быть функцией без возвращаемого значения, первый аргумент которой — *T, а остальные — типы, которые нужно fuzz-тестировать. Например:
f.Fuzz(func(t *testing.T, b []byte, i int) { ... })
Разрешены следующие типы: []byte, string, bool, byte, rune, float32, float64, int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64. В будущем могут быть добавлены и другие типы.
ff не должна вызывать методы *F, например (*F).Log, (*F).Error, (*F).Skip. Вместо этого используйте соответствующие методы *T. Единственные методы *F, разрешенные в функции (*F).Fuzz, это (*F).Failed и (*F).Name.
Эта функция должна быть быстрой и детерминированной, а ее поведение не должно зависеть от общего состояния. Никакие изменяемые входные аргументы или указатели на них не должны храниться между запусками функции fuzz, так как память, поддерживающая их, может быть изменена во время последующего вызова. ff не должна изменять данные, предоставленные fuzz-движком.
При fuzz-тестировании F.Fuzz не возвращается, пока не найдена проблема, не истечёт время (установлено с помощью -fuzztime) или процесс теста не будет прерван сигналом. F.Fuzz должен быть вызван ровно один раз, если не вызван F.Skip или F.Fail.
func (*F) Helper 1.18
func (f *F) Helper()
Helper помечает вызывающую функцию как вспомогательную функцию теста. При печати информации о файле и строке эта функция будет пропущена. Helper может вызываться одновременно из нескольких горутин.
func (*F) Log 1.18
func (c *F) Log(args ...any)
Log форматирует свои аргументы с помощью стандартного форматирования, аналогично Println, и записывает текст в журнал ошибок. Для тестов текст будет напечатан только если тест завершится с ошибкой или установлен флаг -test.v. Для бенчмарков текст всегда печатается, чтобы избежать зависимости производительности от флага -test.v.
func (*F) Logf 1.18
func (c *F) Logf(format string, args ...any)
Logf форматирует свои аргументы согласно формату, аналогично Printf, и записывает текст в журнал ошибок. Конец строки добавляется, если он не был указан. Для тестов текст будет напечатан только если тест завершится с ошибкой или установлен флаг -test.v. Для бенчмарков текст всегда печатается, чтобы избежать зависимости производительности от флага -test.v.
func (*F) Name 1.18
func (c *F) Name() string
Name возвращает имя выполняемого (под-)теста или бенчмарка.
Имя включает имя теста вместе с именами вложенных подтестов. Если у двух подтестов-братьев одинаковое имя, Name добавит суффикс, чтобы гарантировать уникальность возвращаемого имени.
func (*F) Setenv 1.18
func (c *F) Setenv(key, value string)
Setenv вызывает os.Setenv(key, value) и использует Cleanup для восстановления переменной среды до ее исходного значения после завершения теста.
Поскольку Setenv влияет на весь процесс, его нельзя использовать в параллельных тестах или тестах с параллельными предками.
func (*F) Skip 1.18
func (c *F) Skip(args ...any)
Skip эквивалентен Log, за которым следует SkipNow.
func (*F) SkipNow 1.18
func (c *F) SkipNow()
SkipNow помечает тест как пропущенный и останавливает его выполнение, вызвав runtime.Goexit. Если тест завершается с ошибкой (см. Error, Errorf, Fail) и затем пропускается, он всё равно считается завершившимся с ошибкой. Выполнение продолжится на следующем тесте или бенчмарке. См. также FailNow. SkipNow должен вызываться из горутины, выполняющей тест, а не из других горутин, созданных во время теста. Вызов SkipNow не останавливает другие горутины.
func (*F) Skipf 1.18
func (c *F) Skipf(format string, args ...any)
Skipf эквивалентен Logf, за которым следует SkipNow.
func (*F) Skipped 1.18
func (f *F) Skipped() bool
Skipped сообщает, был ли тест пропущен.
func (*F) TempDir 1.18
func (c *F) TempDir() string
TempDir возвращает временную директорию для использования тестом. Директория автоматически удаляется при завершении теста и всех его подтестов. Каждый последующий вызов t.TempDir возвращает уникальную директорию; если создание директории завершилось ошибкой, TempDir завершает тест, вызвав Fatal.
type InternalBenchmark
InternalBenchmark — это внутренний тип, но экспортированный, потому что он используется между пакетами; он является частью реализации команды «go test».
type InternalBenchmark struct {
Name string
F func(b *B)
}
type InternalExample
type InternalExample struct {
Name string
F func()
Output string
Unordered bool // Go 1.7
}
type InternalFuzzTarget 1.18
InternalFuzzTarget — это внутренний тип, но экспортированный, потому что он используется между пакетами; он является частью реализации команды «go test».
type InternalFuzzTarget struct {
Name string
Fn func(f *F)
}
type InternalTest
InternalTest — это внутренний тип, но экспортированный, потому что он используется между пакетами; он является частью реализации команды «go test».
type InternalTest struct {
Name string
F func(*T)
}
type M 1.4
M — это тип, передаваемый функции TestMain для запуска фактических тестов.
type M struct {
// contains filtered or unexported fields
}
func MainStart 1.4
func MainStart(deps testDeps, tests []InternalTest, benchmarks []InternalBenchmark, fuzzTargets []InternalFuzzTarget, examples []InternalExample) *M
MainStart предназначен для использования тестами, сгенерированными командой «go test». Он не предназначен для прямого вызова и не подчиняется документу совместимости Go 1. Он может изменять свою сигнатуру от релиза к релизу.
func (*M) Run 1.4
func (m *M) Run() (code int)
Run запускает тесты. Он возвращает код выхода, который следует передать os.Exit.
type PB 1.3
PB используется командой RunParallel для запуска параллельных бенчмарков.
type PB struct {
// contains filtered or unexported fields
}
func (*PB) Next 1.3
func (pb *PB) Next() bool
Next сообщает, есть ли ещё итерации для выполнения.
type T
T — это тип, передаваемый функциям Test для управления состоянием теста и поддержки отформатированных журналов тестов.
Тест завершается, когда его функция Test возвращается или вызывает любой из методов FailNow, Fatal, Fatalf, SkipNow, Skip или Skipf. Эти методы, а также метод Parallel, должны вызываться только из горутины, выполняющей функцию Test.
Другие методы отчётности, такие как варианты Log и Error, могут вызываться одновременно из нескольких горутин.
type T struct {
// contains filtered or unexported fields
}
func (*T) Chdir 1.24
func (t *T) Chdir(dir string)
Chdir вызывает os.Chdir(dir) и использует Cleanup для восстановления текущей рабочей директории к её исходному значению после теста. В Unix также устанавливается переменная среды PWD на время теста.
Поскольку Chdir влияет на весь процесс, его нельзя использовать в параллельных тестах или тестах с параллельными предками.
func (*T) Cleanup 1.14
func (c *T) Cleanup(f func())
Cleanup регистрирует функцию, которая должна быть вызвана при завершении теста (или подтеста) и всех его подтестов. Функции Cleanup вызываются в порядке, обратном порядку их добавления.
func (*T) Context 1.24
func (c *T) Context() context.Context
Context возвращает контекст, который отменяется незадолго до вызова зарегистрированных функций Cleanup.
Функции Cleanup могут ожидать любых ресурсов, которые завершаются в контексте Context.Done перед завершением теста или бенчмарка.
func (*T) Deadline 1.15
func (t *T) Deadline() (deadline time.Time, ok bool)
Deadline сообщает о времени, когда тестовый бинарник превысит заданный в флаго -timeout таймаут.
Результат ok равен false, если флаг -timeout указывает на отсутствие таймаута (0).
func (*T) Error
func (c *T) Error(args ...any)
Error эквивалентен Log, за которым следует Fail.
func (*T) Errorf
func (c *T) Errorf(format string, args ...any)
Errorf эквивалентен Logf, за которым следует Fail.
func (*T) Fail
func (c *T) Fail()
Fail помечает функцию как завершившуюся с ошибкой, но продолжает выполнение.
func (*T) FailNow
func (c *T) FailNow()
FailNow помечает функцию как завершившуюся с ошибкой и останавливает её выполнение, вызвав runtime.Goexit (который затем выполняет все отложенные вызовы в текущей горутине). Выполнение продолжится на следующем тесте или бенчмарке. FailNow должен вызываться из горутины, выполняющей функцию теста или бенчмарка, а не из других горутин, созданных во время теста. Вызов FailNow не останавливает другие горутины.
func (*T) Failed
func (c *T) Failed() bool
Failed сообщает, завершилась ли функция с ошибкой.
func (*T) Fatal
func (c *T) Fatal(args ...any)
Fatal эквивалентен Log, за которым следует FailNow.
func (*T) Fatalf
func (c *T) Fatalf(format string, args ...any)
Fatalf эквивалентен Logf, за которым следует FailNow.
func (*T) Helper 1.9
func (c *T) Helper()
Helper помечает вызывающую функцию как вспомогательную функцию теста. При выводе информации о файле и строке эта функция будет пропущена. Helper может вызываться одновременно из нескольких горутин.
func (*T) Log
func (c *T) Log(args ...any)
Log форматирует свои аргументы с помощью стандартного форматирования, аналогичного Println, и записывает текст в журнал ошибок. Для тестов текст будет выведен только в случае ошибки теста или если установлен флаг -test.v. Для бенчмарков текст всегда выводится, чтобы избежать зависимости производительности от значения флага -test.v.
func (*T) Logf
func (c *T) Logf(format string, args ...any)
Logf форматирует свои аргументы в соответствии с форматом, аналогично Printf, и записывает текст в журнал ошибок. В конце добавляется перенос строки, если он не указан. Для тестов текст будет выведен только в случае ошибки теста или если установлен флаг -test.v. Для бенчмарков текст всегда выводится, чтобы избежать зависимости производительности от значения флага -test.v.
func (*T) Name 1.8
func (c *T) Name() string
Name возвращает имя выполняемого (под-)теста или бенчмарка.
Имя будет содержать имя теста вместе с именами вложенных подтестов. Если у двух подтестов-братьев одинаковое имя, Name добавит суффикс, чтобы гарантировать уникальность возвращаемого имени.
func (*T) Parallel
func (t *T) Parallel()
Parallel сигнализирует, что этот тест должен выполняться параллельно с (и только с) другими параллельными тестами. Когда тест выполняется несколько раз из-за использования флага -test.count или -test.cpu, несколько экземпляров одного теста никогда не выполняются параллельно друг с другом.
func (*T) Run 1.7
func (t *T) Run(name string, f func(t *T)) bool
Run выполняет f как подтест t с именем name. Он выполняет f в отдельной горутине и блокируется до тех пор, пока f не вернётся или не вызовет t.Parallel, чтобы стать параллельным тестом. Run сообщает, успешно ли завершился f (или по крайней мере не завершился с ошибкой до вызова t.Parallel).
Run может вызываться одновременно из нескольких горутин, но все такие вызовы должны вернуться до возврата внешней функции теста для t.
func (*T) Setenv 1.17
func (t *T) Setenv(key, value string)
Setenv вызывает os.Setenv(key, value) и использует Cleanup для восстановления переменной окружения к её исходному значению после теста.
Поскольку Setenv влияет на весь процесс, его нельзя использовать в параллельных тестах или тестах с параллельными предками.
func (*T) Skip 1.1
func (c *T) Skip(args ...any)
Skip эквивалентен Log, за которым следует SkipNow.
func (*T) SkipNow 1.1
func (c *T) SkipNow()
SkipNow помечает тест как пропущенный и останавливает его выполнение, вызвав runtime.Goexit. Если тест завершается с ошибкой (см. Error, Errorf, Fail) и затем пропускается, он всё равно считается завершившимся с ошибкой. Выполнение продолжится на следующем тесте или бенчмарке. См. также FailNow. SkipNow должен вызываться из горутины, выполняющей тест, а не из других горутин, созданных во время теста. Вызов SkipNow не останавливает другие горутины.
func (*T) Skipf 1.1
func (c *T) Skipf(format string, args ...any)
Skipf эквивалентен Logf, за которым следует SkipNow.
func (*T) Skipped 1.1
func (c *T) Skipped() bool
Skipped сообщает, был ли тест пропущен.
func (*T) TempDir 1.15
func (c *T) TempDir() string
TempDir возвращает временную директорию для использования тестом. Директория автоматически удаляется при завершении теста и всех его подтестов. Каждый последующий вызов t.TempDir возвращает уникальную директорию; если создание директории завершилось ошибкой, TempDir завершает тест, вызвав Fatal.
type TB 1.2
TB — это интерфейс, общий для T, B и F.
type TB interface {
Cleanup(func())
Error(args ...any)
Errorf(format string, args ...any)
Fail()
FailNow()
Failed() bool
Fatal(args ...any)
Fatalf(format string, args ...any)
Helper()
Log(args ...any)
Logf(format string, args ...any)
Name() string
Setenv(key, value string)
Chdir(dir string)
Skip(args ...any)
SkipNow()
Skipf(format string, args ...any)
Skipped() bool
TempDir() string
Context() context.Context
// contains filtered or unexported methods
} Подкаталоги
| Имя | Описание |
|---|---|
| .. | |
| fstest | Пакет fstest реализует поддержку тестирования реализаций и пользователей файловых систем. |
| iotest | Пакет iotest реализует классы Readers и Writers, полезные в основном для тестирования. |
| quick | Пакет quick реализует служебные функции для помощи в тестировании «черного ящика». |
| slogtest | Пакет slogtest реализует поддержку тестирования реализаций log/slog.Handler. |
| synctest | Пакет synctest предоставляет поддержку тестирования конкурентного кода. |
© Google, Inc.
Licensed under the Creative Commons Attribution License 3.0.
http://golang.org/pkg/testing/
