Para o que você de fato escreveria testes num pipeline de machine learning?

Teste as partes determinísticas de forma adequada e as estocásticas de forma comportamental. Faça testes unitários das transformações de feature contra fixtures, imponha contratos de schema e de faixa nas entradas, mantenha um teste de linha dourada que carrega o pipeline serializado e checa que entradas conhecidas produzem scores conhecidos, e escreva testes comportamentais nas saídas do modelo (invariância, expectativas direcionais) em vez de assegurar um número exato de acurácia.

A maior parte de um pipeline é código comum e se testa exatamente como código comum. Transformações de feature ganham testes unitários contra fixtures pequenas, incluindo os casos feios: nulos, uma categoria nunca vista no treino, um valor negativo onde só se esperavam positivos. Os dados de entrada ganham checagens de contrato, ou seja schema, tipos, faixas e taxas de nulo esperadas, rodadas como porta antes do treino em vez de descobertas depois como um modelo estranho. Depois um teste de linha dourada, em que eu guardo um pipeline serializado e um punhado de entradas fixas com os scores esperados, e o CI falha se uma refatoração mudar isso. Isso já pegou mudanças silenciosas de pré processamento para mim mais de uma vez. Para o modelo em si eu não asseguro acurácia acima de algum número, porque isso é instável e é uma porta ruim. Eu escrevo testes comportamentais no lugar: invariância, ou seja mudar um campo irrelevante mal move o score, e expectativas direcionais, ou seja aumentar uma feature que sabemos ser monotonicamente relacionada move a previsão para o lado certo. Treinos completos são lentos demais para todo commit, então esses vão para a rodada noturna, com um treino de fumaça rápido numa amostra minúscula no CI para provar que o pipeline ainda roda fim a fim.