Come testate un encoder?

Ho qualcosa del genere:

public byte[] EncodeMyObject(MyObject obj)

Sono stato test di unità in questo modo:

byte[] expectedResults = new byte[3]{ 0x01, 0x02, 0xFF };
Assert.IsEqual(expectedResults, EncodeMyObject(myObject));

EDIT: I due modi che ho visto proposti sono:

1) Utilizzo di valori previsti codificati, come nell'esempio sopra.

2) Utilizzo di un decodificatore per decodificare l'array di byte codificato e confrontare gli oggetti di input / output.

Il problema che vedo con il metodo 1 è che è molto fragile e richiede molti valori codificati.

Il problema con il metodo 2 è che il test dell'encoder dipende dal corretto funzionamento del decoder. Se l'encoder / decodificatore si rompono allo stesso modo (nello stesso posto), i test potrebbero produrre falsi positivi.

Questi potrebbero benissimo essere gli unici modi per testare questo tipo di metodo. Se è così, allora va bene. Sto ponendo la domanda per vedere se ci sono strategie migliori per questo tipo di test. Non riesco a rivelare gli interni dell'encoder particolare su cui sto lavorando. Sto chiedendo in generale come risolveresti questo tipo di problema e non credo che gli interni siano importanti. Supponiamo che un determinato oggetto di input produca sempre lo stesso array di byte di output.

Ti trovi in ​​una situazione un po 'odiosa lì. Se avessi un formato statico in cui stavi codificando, il tuo primo metodo sarebbe la strada da percorrere. Se fosse solo il tuo formato, e nessun altro doveva decodificare oltre al secondo metodo sarebbe la strada da percorrere. Ma non rientri in nessuna di queste categorie.

Quello che farei è cercare di scomporre le cose in base al livello di astrazione.

Quindi inizierei con qualcosa a livello di bit, che testerei qualcosa di simile

bitWriter = new BitWriter();
bitWriter.writeInt(42, bits = 7);
assertEqual( bitWriter.data(), {0x42} )

Quindi l'idea è che il bitwriter sappia scrivere i tipi di campi più primitivi, come gli ints.

Tipi più complessi verrebbero implementati usando e testati qualcosa del tipo:

bitWriter = new BitWriter();
writeDate(bitWriter, new Datetime(2001, 10, 4));

bitWriter2 = new BitWriter();
bitWriter2.writeInt(2001, 12)
bitWriter2.writeInt(10, 4)
bitWriter2.writeInt(4, 6)

assertEquals(bitWriter.data(), bitWriter2.data() )

Si noti che ciò evita qualsiasi conoscenza di come vengono impacchettati i bit effettivi. Questo è testato dal test precedente e per questo test supponiamo praticamente che funzioni.

Quindi al prossimo livello di astrazione avremmo

bitWriter = new BitWriter();
encodeObject(bitWriter, myObject);


bitWriter2 = new BitWriter();
bitWriter2.writeInt(42, 32)
writeDate(bitWriter2, new Datetime(2001, 10, 4));
writeVarString(bitWriter2, "alphanumeric");

assertEquals(bitWriter.data(), bitWriter2.data() )

quindi, ancora una volta, non proviamo a includere la conoscenza di come i varstrings o le date o i numeri siano effettivamente codificati. In questo test, siamo interessati solo alla codifica prodotta da encodeObject.

Il risultato finale è che se il formato per le date viene modificato, dovrai correggere i test che coinvolgono effettivamente le date, ma tutti gli altri codici e test non riguardano il modo in cui le date vengono effettivamente codificate e una volta aggiornato il codice per creare che funziona, tutti quei test passeranno bene.

Dipende. Se la codifica è qualcosa di completamente risolto, in cui ogni implementazione dovrebbe creare esattamente lo stesso output, non ha senso controllare altro che verificare che gli input di esempio siano mappati esattamente agli output previsti. Questo è il test più ovvio, e probabilmente anche il più semplice da scrivere.

Se esiste uno spazio di manovra con output alternativi, come nello standard MPEG (ad esempio ci sono alcuni operatori che è possibile applicare all'input, ma si è liberi di scambiare lo sforzo di codifica rispetto alla qualità dell'output o allo spazio di archiviazione), quindi è meglio applicare il ha definito la strategia di decodifica per l'output e verifica che sia uguale all'input o, se la codifica è in perdita, che sia ragionevolmente vicina all'input originale. È più difficile da programmare, ma ti protegge da eventuali miglioramenti futuri che potrebbero essere apportati al tuo codificatore.

Prova questo encode(decode(coded_value)) == coded_valuee decode(encode(value)) == value. Se lo desideri, puoi dare un input casuale ai test.

È ancora possibile che sia l'encoder che il decoder siano rotti in modo complementare, ma ciò sembra abbastanza improbabile a meno che tu non abbia un equivoco concettuale dello standard di codifica. Fare test hardcoded dell'encoder e del decoder (come stai già facendo) dovrebbe evitare questo.

Se hai accesso a un'altra implementazione di questo che è noto per funzionare, puoi almeno usarla per avere fiducia che la tua implementazione sia buona anche se usarla nei test unitari sarebbe impossibile.

Test per i requisiti .

Se i requisiti sono solo "codificare in un flusso di byte che quando viene decodificato produce un oggetto equivalente", testare il codificatore decodificandolo. Se stai scrivendo sia l'encoder che il decoder, testali insieme. Non possono avere "errori corrispondenti". Se lavorano insieme, il test ha esito positivo.

Se ci sono altri requisiti per il flusso di dati, dovrai verificarli esaminando i dati codificati.

Se il formato codificato è predefinito, allora dovrai verificare i dati codificati rispetto al risultato previsto, come hai fatto, o (meglio) ottenere un decodificatore di riferimento che può essere considerato attendibile per eseguire la verifica. L'uso di un decodificatore di riferimento elimina la possibilità di interpretare erroneamente le specifiche del formato.

A seconda del framework di test e del paradigma che stai usando, puoi comunque usare il modello Arrange Act Assert per questo come hai detto.

[TestMethod]
public void EncodeMyObject_ForValidInputs_Encodes()
{
    //Arrange object under test
    MyEncoder encoderUnderTest = new MyEncoder();
    MyObject validObject = new MyOjbect();
    //arrange object for condition under test

    //Act
    byte[] actual = encoderUnderTest.EncodeMyObject(myObject);

    //Assert
    byte[] expected = new byte[3]{ 0x01, 0x02, 0xFF };
    Assert.IsEqual(expected, actual);
}

Dovresti conoscere i requisiti EncodeMyObject()e puoi usare questo modello per testare ciascuno di essi per criteri validi e non validi, disponendo ciascuno di essi e codificando il risultato atteso expected, allo stesso modo per il decodificatore.

Dal momento che le aspettative sono codificate, queste saranno fragili se hai un cambiamento enorme.

Potresti essere in grado di automatizzare con qualcosa guidato da parametri (dai un'occhiata a Pex ) o se stai facendo DDD o BDD dai un'occhiata a gerkin / cucumber .

Puoi decidere cosa è importante per te.

È importante per te che un oggetto sopravviva al round trip e che il formato esatto del filo non sia davvero importante? Oppure il formato esatto del filo è una parte importante della funzionalità del tuo codificatore e decodificatore?

Se il primo, basta assicurarsi che gli oggetti sopravvivano al viaggio di andata e ritorno. Se l'encoder e il decoder sono entrambi rotti in modo esattamente complementare, non ti interessa davvero.

In quest'ultimo caso, è necessario verificare che il formato del filo sia come previsto per gli input forniti. Ciò significa testare direttamente il formato oppure utilizzare un'implementazione di riferimento. Ma avendo testato le basi, potresti ottenere valore da ulteriori test di andata e ritorno, che dovrebbero essere più facili da scrivere in volume.