evitando l'hard coding della conoscenza dell'algoritmo nei test?

1

Ho un pacchetto di codice che suppone di dirmi dove allocare gli elementi. Quando aggiungo un nuovo elemento, potrebbe richiedere il riposizionamento di elementi esistenti per mantenere il mio 'albero' in un formato che promette una ricerca log-n. In definitiva, quando gli consegno un sistema attuale e nuovi elementi da aggiungere, dovrei ottenere un elenco di dove aggiungere nuovi elementi e quando / dove sono stati spostati i vecchi elementi.

Voglio verificare che il set restituito sia valido, ma non sono sicuro di come farlo. Posso facilmente verificare se gli elementi sono collocati in posizioni valide, cioè in luoghi che non rompono le ipotesi sul mio 'albero', ma ciò non garantisce che abbia fatto il minimo ed il più efficace movimento di elementi. Tuttavia, non riesco a pensare a come controllare che le mosse siano efficaci senza essenzialmente riscrivere gran parte del pacchetto solo per testare i risultati.

Da quando ho scritto il pacchetto conosco alcuni dettagli specifici sull'implementazione. So che A verrà spostato in B perché so esattamente quale logica è stata utilizzata per decidere la mossa, ma questa è l'implementazione specifica. Ci sono casi in cui ho molte scelte ugualmente valide e scelgo un modo quando posso sceglierne un altro. È 'giusto' fare questo tipo di test funzionali utilizzando la mia comprensione dell'algoritmo per specificare in modo specifico cosa dovrebbe essersi spostato dove? se no, in quale altro modo potrei scrivere il test per avere qualche idea che non sto facendo il più inefficiente, ma valido, possibile muovere?

    
posta dsollen 11.03.2014 - 22:25
fonte

2 risposte

3

Sembra che tu stia cercando di assicurarti che:

  1. La tua interfaccia è valida
  2. La tua implementazione è efficiente
  3. Non regredisci

Interfaccia valida

Scrivi dei test che verificano che, per ogni metodo di interfaccia, il risultato sia valido e lascia perdere. Se ti aspetti un elenco valido di luoghi come output di una funzione, verifica che cosa stai ricevendo. Se si prevede che determinati input possano causare eccezioni o generare errori, testarlo. Ecc ...

Implementazione efficiente

Devi avere una sorta di misura dell'efficienza che stai usando per assicurarti che le tue soluzioni siano, in effetti, le più efficienti possibili. Sembra "numero di mosse", nel tuo caso.

Quindi, crea manualmente alcuni input, per i quali controlli manualmente che il numero di mosse sia ottimale. Quindi, esegui gli input tramite il tuo algoritmo e controlla che il numero di mosse produca esattamente le tue aspettative (forse controlla anche che la soluzione sia valida, per ragioni di sanità). Se il numero è più alto, c'è qualcosa di sbagliato nel tuo algoritmo; se il numero è più basso, qualcosa è sbagliato con la tua mano-matematica;)

Vale a dire, fornire un elenco di input e una misurazione dell'efficienza appropriata, prevista.

Progetta gli input per i casi di stress corner per qualsiasi soluzione generale al tuo problema - input per i quali è particolarmente difficile trovare soluzioni efficienti, o per le quali il tuo algoritmo potrebbe rompersi (e continuare ad eseguirlo all'infinito, per esempio).

Regressione

Genera / trova / ottieni un set di input che riflettono la vita reale per il tuo algoritmo.

Esegui l'algoritmo rispetto agli input.

Registrare e memorizzare misure valide per i risultati (misurazioni dalla sezione Implementazione efficiente e altre che probabilmente non dipenderanno dall'algoritmo specifico.

Scrivi test che assicurano che ogni esecuzione del tuo algoritmo sui dati reali produca risultati validi, che corrispondono esattamente alle misurazioni di sessioni conosciute, stabili e precedenti.

    
risposta data 11.03.2014 - 22:50
fonte
0

Sembra che i tuoi test debbano riguardare due cose:

  1. L'API del tuo pacchetto - come lo userà il mondo esterno
  2. Dettagli interni del pacchetto - assicurandoti che l'implementazione corrente funzioni correttamente

Quindi scriverei test in entrambe le aree e dividerli in modo che il loro scopo sia chiaro. Ad esempio, classi separate, spazi dei nomi o pacchetti. Se modifichi l'implementazione, la prima serie di test non dovrebbe essere modificata, assicurando che l'API non sia interrotta.

    
risposta data 11.03.2014 - 22:39
fonte

Leggi altre domande sui tag