Sou a favor de testes aleatórios e escrevo-os. No entanto, se eles são apropriados em um ambiente de construção específico e em quais suítes de teste eles devem ser incluídos é uma questão mais sutil.
Execute localmente (por exemplo, durante a noite em sua caixa de desenvolvimento) testes aleatórios descobriram bugs óbvios e obscuros. Os obscuros são misteriosos o suficiente para que eu acho que o teste aleatório foi realmente o único realista a liberá-los. Como teste, peguei um bug difícil de encontrar descoberto por meio de testes aleatórios e tive uma meia dúzia de desenvolvedores de crack revisando a função (cerca de uma dúzia de linhas de código) onde ocorreu. Nenhum foi capaz de detectá-lo.
Muitos de seus argumentos contra dados aleatórios são sabores de "o teste não é reproduzível". No entanto, um teste aleatório bem escrito capturará a semente usada para iniciar a semente aleatória e a produzirá em falha. Além de permitir que você repita o teste manualmente, isso permite que você crie trivialmente um novo teste que testa o problema específico codificando a semente desse teste. É claro que é provavelmente melhor codificar manualmente um teste explícito que cubra esse caso, mas a preguiça tem suas virtudes, e isso ainda permite que você gere essencialmente automaticamente novos casos de teste a partir de uma semente que falhou.
O único argumento que você enfatiza que não posso debater é que isso quebra os sistemas de construção. A maioria dos testes de compilação e integração contínua espera que os testes façam o mesmo sempre. Portanto, um teste que falha aleatoriamente cria caos, falha aleatória e aponta os dedos para mudanças inofensivas.
Uma solução, então, é ainda executar seus testes aleatórios como parte dos testes de compilação e IC, mas executá-lo com uma semente fixa, para um número fixo de iterações . Portanto, o teste sempre faz a mesma coisa, mas ainda explora um monte de espaço de entrada (se você o executar para várias iterações).
Localmente, por exemplo, ao alterar a classe em questão, você pode executá-la para mais iterações ou com outras sementes. Se o teste aleatório se tornar cada vez mais popular, você pode imaginar um conjunto específico de testes que são conhecidos por serem aleatórios, que podem ser executados com sementes diferentes (portanto, com cobertura crescente ao longo do tempo) e onde falhas não significariam a mesma coisa como sistemas de IC determinísticos (ou seja, execuções não são associadas 1: 1 a alterações de código e, portanto, você não aponta uma alteração específica quando as coisas falham).
Há muito o que dizer sobre os testes randomizados, especialmente os bem escritos, por isso não seja rápido demais para descartá-los!