t.Log()não aparecerá até que o teste seja concluído, portanto, se você estiver tentando depurar um teste que está travando ou com desempenho ruim, parece que você precisa usar fmt.
Sim: era esse o caso até Go 1.13 (agosto de 2019) incluído.
E isso foi seguido na golang.orgedição 24929
Considere os seguintes testes automatizados (bobos):
func TestFoo(t *testing.T) {
t.Parallel()
for i := 0; i < 15; i++ {
t.Logf("%d", i)
time.Sleep(3 * time.Second)
}
}
func TestBar(t *testing.T) {
t.Parallel()
for i := 0; i < 15; i++ {
t.Logf("%d", i)
time.Sleep(2 * time.Second)
}
}
func TestBaz(t *testing.T) {
t.Parallel()
for i := 0; i < 15; i++ {
t.Logf("%d", i)
time.Sleep(1 * time.Second)
}
}
Se eu executar go test -v, não recebo nenhuma saída de log até que tudo TestFooseja feito , nenhuma saída até que tudo TestBarseja feito e, novamente, nenhuma saída até que tudo TestBazseja feito.
Isso é bom se os testes estiverem funcionando, mas se houver algum tipo de bug, há alguns casos em que o armazenamento em buffer da saída do log é problemático:
- Ao iterar localmente, quero ser capaz de fazer uma alteração, executar meus testes, ver o que está acontecendo nos logs imediatamente para entender o que está acontecendo, pressione CTRL + C para encerrar o teste mais cedo se necessário, faça outra alteração, execute os testes e assim por diante.
E seTestFoo for lento (por exemplo, é um teste de integração), não recebo nenhuma saída de log até o final do teste. Isso diminui significativamente a iteração.
- Se
TestFoohouver um bug que faz com que ele trave e nunca seja concluído, eu não obteria nenhuma saída de log. Nestes casos, t.Loge t.Logfsão inúteis.
Isso torna a depuração muito difícil.
- Além disso, não apenas recebo nenhuma saída de log, mas se o teste travar por muito tempo, o tempo limite do teste Go elimina o teste após 10 minutos, ou se eu aumentar esse tempo limite, muitos servidores de CI também encerrarão os testes se não houver log de saída após um determinado período de tempo (por exemplo, 10 minutos em CircleCI).
Portanto, agora meus testes foram interrompidos e não tenho nada nos registros que me diga o que aconteceu.
Mas para (possivelmente) Go 1.14 (Q1 2020): CL 127120
teste: fluxo de saída de registro em modo detalhado
A saída agora é:
=== RUN TestFoo
=== PAUSE TestFoo
=== RUN TestBar
=== PAUSE TestBar
=== RUN TestGaz
=== PAUSE TestGaz
=== CONT TestFoo
TestFoo: main_test.go:14: hello from foo
=== CONT TestGaz
=== CONT TestBar
TestGaz: main_test.go:38: hello from gaz
TestBar: main_test.go:26: hello from bar
TestFoo: main_test.go:14: hello from foo
TestBar: main_test.go:26: hello from bar
TestGaz: main_test.go:38: hello from gaz
TestFoo: main_test.go:14: hello from foo
TestGaz: main_test.go:38: hello from gaz
TestBar: main_test.go:26: hello from bar
TestFoo: main_test.go:14: hello from foo
TestGaz: main_test.go:38: hello from gaz
TestBar: main_test.go:26: hello from bar
TestGaz: main_test.go:38: hello from gaz
TestFoo: main_test.go:14: hello from foo
TestBar: main_test.go:26: hello from bar
--- PASS: TestFoo (1.00s)
--- PASS: TestGaz (1.00s)
--- PASS: TestBar (1.00s)
PASS
ok dummy/streaming-test 1.022s
Na verdade, está no Go 1.14, como Dave Cheney atesta em " go test -vfluxo de saída ":
No Go 1.14, go test -vo fluxo de t.Logsaída será transmitido à medida que acontecer, em vez de armazená-lo até o final do teste .
No Go 1.14, as linhas fmt.Printlne t.Logsão intercaladas , em vez de aguardar a conclusão do teste, demonstrando que a saída do teste é transmitida quando go test -vé usada.
Vantagem, de acordo com Dave:
Esta é uma grande melhoria de qualidade de vida para testes de estilo de integração que geralmente são repetidos por longos períodos quando o teste está falhando.
A t.Logsaída de streaming ajudará os Gophers a depurar essas falhas de teste sem ter que esperar até que todo o teste expire para receber sua saída.