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

Verifica la funzione non l'unità

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

Test futuri che utilizzano gli stessi input xml possono fare un confronto di file binari con il riferimento.

Se un confronto a livello di file non è soddisfacente, visualizza il PDF alla fine del test e fai screenshot, quindi confronta il test automatico con gli screenshot di riferimento.

Normalmente in un caso come questo si astraggono tutto ciò che non è possibile testare dietro un'implementazione che è possibile utilizzare con un'interfaccia. Farò semplicemente qualcosa di sciocco come un PDF builder perché sembra ragionevole.

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

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

Puoi quindi prendere in giro l'IPdfBuilder nei tuoi test per fare quello che vuoi. Ciò significa spesso che devi iniziare a utilizzare un contenitore IoC ( link e link come luogo di partenza) se non ne stai usando uno ora.

E i test che non sono unit test vengono spesso chiamati test di integrazione. Spesso i test di integrazione complicati non ne valgono la pena, quindi è sufficiente astrarre questa parte e ridurre la quantità di logica aziendale in quella astrazione, in modo da poterla testare in un test unitario.

Fammi sapere se questo non è completamente chiaro.

Ho creato qualcosa di molto simile un po 'indietro, e ho appena usato i test visivi di base. I test non devono essere automatizzati, quindi non c'è niente di sbagliato semplicemente cercando un risultato atteso (ovviamente, in una varietà di situazioni che sono predeterminate). Spesso, un'immagine vale più di mille test in cui le immagini sono interessate . Uso estensivamente i test di unità automatizzate, ma penso che alcune persone possano essere un po 'trascurate quando si entra nel test della GUI, o qualsiasi cosa visiva IMHO. Con determinati prodotti, riconosco che questo approccio "abbastanza buono" non sarà sufficiente per YMMV.

Sarei un po 'preoccupato, tuttavia, per le esternazioni imperdibili. Questo può essere un segno di accoppiamento stretto, che è buono da evitare come regola generale, ma non speculerò troppo sul codice in questo senso senza ulteriori dettagli.