Come si scrivono i test per il codice che dipende da implementazioni esterne concrete che non possono essere derise?

Antefatto: sto pensando di provare a introdurre il concetto di unit test ai miei colleghi creando alcuni per un modulo su cui sto lavorando; i requisiti sono cambiati di recente e richiedono alcune ulteriori astrazioni / interazioni, quindi sembra un buon modo per sviluppare una serie di test che "dimostreranno" che funziona senza dover cercare manualmente l'applicazione.

Il problema, tuttavia, è che il modulo si basa su fattori esterni non modificabili, vale a dire PDF e XSL. Fondamentalmente ho letto XML dal database e vi ho applicato una trasformazione XSL, quindi l'ho convertito in PDF usando una libreria chiamata ABCPDF. Questo PDF viene quindi unito a un altro PDF basato su un modello statico. So che posso testare l'XML e assicurarmi che i valori siano corretti, ma molti dei potenziali bug e problemi sono correlati alla visualizzazione effettiva del documento finito, ad esempio minuzie come la lunghezza delle stringhe di testo, dove determinate aree HTML sono situato in relazione al documento, ecc. È anche possibile testare queste cose (mi rendo conto che si tratta probabilmente di test di integrazione o .. il terzo tipo di test di cui dimentico il nome [non test di accettazione, l'altro tipo] e non unità test) dal momento che non posso, per quanto ne so, prendere in giro un PDF facilmente prima di crearlo, quindi rileggerlo o creare una stringa HTML (ovvero XML trasformato) e analizzarlo manualmente per verificare la presenza di determinate celle della tabella in relazione con altre celle della tabella.

In una situazione come questa, dovrei concentrarmi solo sui test unitari per accertarmi che le informazioni siano corrette e che sia possibile creare il PDF o unirli o qualsiasi altra cosa e ricorrere al test manuale per i problemi di visualizzazione effettivi?

Prova la funzione non l'unità

Utilizzando input xml noti, genera un PDF e verifica manualmente (e meticolosamente) che sia corretto. Quindi salvarlo come riferimento.

I test futuri che utilizzano gli stessi input XML possono fare un confronto di file binario con il riferimento.

Se un confronto a livello di file non è soddisfacente, visualizzare il PDF alla fine del test e acquisire schermate, quindi confrontare automaticamente il test con le schermate di riferimento.

Normalmente in un caso come questo si astratto tutto ciò che non è possibile verificare dietro un'implementazione che è possibile utilizzare con un'interfaccia. Farò semplicemente qualcosa di stupido come PDF Builder perché sembra ragionevole.

public class PdfBuilder : IPdfBuilder
{
  public byte[] BuildPdf(...)
  {
    // actual untestable code here
  }
}

public interface IPdfBuilder
{
  byte[] BuildPdf(...);
}

Puoi quindi deridere IPdfBuilder nei tuoi test per fare quello che vuoi. Ciò significa spesso che è necessario iniziare a utilizzare un contenitore IoC ( /programming/871405/why-do-i-need-an-ioc-container-as-opposed-to-straightforward-di-code e /programming/21288/which-net-dependency-injection-frameworks-are-worth-looking-into come punto di partenza) se non ne stai usando uno adesso.

E i test che non sono unit test sono spesso chiamati test di integrazione. I test di integrazione complicati spesso non ne valgono la pena, quindi è sufficiente sottrarre tale parte e ridurre la quantità di logica aziendale in tale astrazione in modo da poterla testare in un unit test.

Fammi sapere se questo non è del tutto chiaro.

Qualche tempo fa ho costruito qualcosa di molto simile e ho usato solo test visivi di base. I test non devono essere automatizzati, quindi non c'è nulla di sbagliato nel cercare un risultato atteso (ovviamente, in una varietà di situazioni predeterminate). Spesso, un'immagine vale mille test per quanto riguarda la grafica . Uso ampiamente i test di unità automatizzati, ma penso che alcune persone possano essere un po 'trascurate quando entrano nei test della GUI o qualsiasi altro IMHO visivo. Con un certo prodotto, riconosco che questo approccio "abbastanza buono" non sarà sufficiente, quindi YMMV.

Sarei un po 'preoccupato, tuttavia, per le esternalità inconfondibili. Questo può essere un segno di accoppiamento stretto, che è bene evitare come regola generale, ma non speculerò troppo sul tuo codice al riguardo senza ulteriori dettagli.