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.org
ediçã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 TestFoo
seja feito , nenhuma saída até que tudo TestBar
seja feito e, novamente, nenhuma saída até que tudo TestBaz
seja 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
TestFoo
houver 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.Log
e t.Logf
sã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 -v
fluxo de saída ":
No Go 1.14, go test -v
o fluxo de t.Log
saída será transmitido à medida que acontecer, em vez de armazená-lo até o final do teste .
No Go 1.14, as linhas fmt.Println
e t.Log
sã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.Log
saí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.