Código de conversão parece simples demais para errar, até o momento em que uma regra de arredondamento ou uma convenção de sinal inverte um preço. A correção é uma pequena tabela de pares conhecidos que todo deploy deve reproduzir exatamente. Monte-a uma vez, a partir de exemplos documentados, e ela pega toda regressão futura em segundos.
A tabela de ouro
Comece com os pares que o conversor de odds publica como seus próprios exemplos, verificado em 2026-10-07. Decimal 2,50 é americano +150 e fracionário 3/2. Americano -200 é decimal 1,50. Decimal 2,00 implica 50%. Um board equilibrado com preço 1,91 nos dois lados implica cerca de 52,36% em cada.
Adicione as linhas de fronteira que o seu código vai realmente encontrar: preços logo acima e logo abaixo do decimal 2,00, onde a fórmula americana muda de sinal, e um valor americano como +100, o menor convencional. Cada linha declara a entrada, as saídas esperadas e a precisão que você aceita.
As regras que sua tabela reforça
O conjunto de fórmulas é curto: probabilidade implícita é 1 dividido pelo preço decimal; fracionário é o decimal menos um expresso como razão; americano é o decimal menos um, vezes 100, em ou acima de 2,00, e -100 dividido pelo decimal-menos-um abaixo. O conversor documenta isso diretamente, verificado em 2026-10-07.
Dois comportamentos merecem linhas explícitas. A regra de rejeição: valores americanos convencionais são +100 ou acima, ou -100 ou abaixo, e zero ou qualquer coisa entre -100 e +100 é rejeitada. Seu código deve recusar essas entradas da mesma forma. E a regra de exibição: decimal exibe com quatro casas, americano com duas, probabilidades com duas. Um teste que compara strings de exibição em vez de valores subjacentes vai falhar intermitentemente por arredondamento.
Testes de ida e volta
A segunda metade da tabela é comportamental: converter para frente e de volta deve cair dentro da sua precisão declarada. A própria nota de precisão do conversor avisa que arredondar um preço exibido e convertê-lo de volta pode mudar os últimos dígitos. Então teste a ida e volta sobre o valor não arredondado, e afirme uma tolerância, nunca uma string exata.
Rode onde o código muda
A tabela pertence à suíte de unidade, ao lado da função de conversão, e deve rodar em cada commit. Quando nada muda, a tabela fica em silêncio; quando alguém toca no formatador para uma nova exibição, a tabela é a proteção. Testes assim são seguro barato, e nunca dormem durante um deploy.
Pares conhecidos, linhas de fronteira, idas e voltas com tolerância. Os bugs de conversão param na tabela.