Vorrei premettere che questa domanda è simile, ma la mia domanda non riguarda la casualità, ma solo il determinismo pignolo, quindi la risposta di "usa un seme conosciuto" non si applica davvero. Allo stesso modo, questa domanda è simile, ma ancora una volta, non mi aspetto che l'algoritmo fallisca mai, ma non so in che modo sarà corretta.
Questa domanda è nata durante il test degli algoritmi grafici. ma non si limita affatto a loro. Alcuni algoritmi come A * possono avere più risposte corrette. A seconda della tua esatta implementazione potresti ricevere una delle diverse risposte, ognuna delle quali è ugualmente corretta. Questo può renderli difficili da testare, perché non sai quale verrà sputato in anticipo, ed è molto dispendioso calcolare le risposte a mano.
Nel mio caso specifico, ho aggirato il problema modificando Floyd-Warshall per sputare ogni possibile percorso più breve e ho trascorso il tempo a testarlo. Ha avuto il vantaggio di essere una buona caratteristica a sé stante. Quindi ho potuto testare altre funzioni in termini di percorsi corretti noti da FW (se il percorso restituito è uno dei percorsi restituiti da FW per quella coppia iniziale / finale, è corretto). Ovviamente, questo funziona solo con grafici densi a causa del funzionamento di FW, ma è comunque bello.
Tuttavia, ciò potrebbe non essere sempre praticabile per tutti gli algoritmi con questa caratteristica. Finora, la migliore risposta che ho trovato è quella di testare le caratteristiche di una risposta corretta, piuttosto che la risposta corretta stessa. Per tornare agli algoritmi del percorso più breve, è possibile verificare il costo del percorso restituito rispetto al costo corretto noto e assicurarsi che il percorso sia valido.
Funziona, ma può correre il rischio di non verificare tutto correttamente, più sono i criteri per la correttezza, soprattutto se la verifica è essa stessa complessa (es. Mentre esistono algoritmi corretti , verificare che un albero di spanning minimo sia un problema difficile noto; probabilmente più difficile di costruzione dell'MST stesso), nel qual caso ora è necessario testare ampiamente il codice di test. Peggio ancora: presumibilmente devi costruire un MST per testare un algoritmo di verifica MST, quindi ora hai un ottimo scenario in cui il tuo test MST si basa sul funzionamento dell'algoritmo di verifica MST e il test dell'algoritmo di verifica MST si basa sul funzionamento del codice di generazione MST.
Infine, esiste il "modo economico", che prevede l'osservazione dell'output, la verifica manuale, quindi la codifica del test per testare l'output appena verificato, ma non è una buona idea poiché potrebbe essere necessario rivedere il test ogni volta che cambiare un po 'l'implementazione (che è ciò che dovrebbe evitare il testing automatizzato).
Ovviamente la risposta dipende dall'algoritmo esatto che stai testando fino a un certo punto, ma mi chiedevo se esistessero delle "migliori pratiche" per verificare algoritmi che hanno diversi output "corretti" definiti e deterministici, ma questi output corretti e precisi sono difficili da sapere in anticipo, e possibilmente difficile persino verificare dopo il fatto.