Comment écrivez-vous des tests pour du code qui dépend d'implémentations externes concrètes qui ne peuvent pas être moquées?

Contexte: Je pense essayer d'introduire le concept de tests unitaires à mes collègues en en créant pour un module sur lequel je travaille; les exigences de celui-ci ont récemment changé et nécessitent quelques abstractions / interactions supplémentaires, donc cela semble être un bon moyen de développer une suite de tests qui "prouveront" que cela fonctionne sans avoir à fouiller manuellement l'application.

Le problème, cependant, est que le module repose sur des facteurs externes non modifiables, à savoir les fichiers PDF et XSL. Fondamentalement, je lis XML à partir de la base de données et y applique une transformation XSL, puis le convertis en PDF à l'aide d'une bibliothèque appelée ABCPDF. Ce PDF est ensuite fusionné avec un autre PDF basé sur un modèle statique. Je sais que je peux tester le XML et m'assurer que les valeurs sont correctes, mais de nombreux bugs et problèmes potentiels sont liés à l'affichage réel du document fini - par exemple, des minuties comme la longueur des chaînes de texte, où certaines zones HTML sont situé par rapport au document, etc. Est-il même possible de tester ces choses (je me rends compte que ce sont probablement des tests d'intégration ou .. le troisième type de test dont j'oublie le nom [pas les tests d'acceptation, l'autre type], et pas l' unité tests) car je ne peux pas, à ma connaissance, simuler un PDF facilement avant de le créer, puis de le lire ou de créer une chaîne HTML (c'est-à-dire du XML transformé) et de l'analyser à la main pour vérifier la présence de certaines cellules de tableau dans par rapport aux autres cellules du tableau.

Dans une situation comme celle-ci, dois-je me concentrer uniquement sur les tests unitaires pour m'assurer que les informations sont correctes et que je peux créer le PDF, ou les fusionner, ou quoi que ce soit et recourir à des tests manuels pour les problèmes d'affichage réels?

Testez la fonction et non l'unité

En utilisant des entrées xml connues, sortez un PDF et vérifiez manuellement (et méticuleusement) qu'il est correct. Enregistrez-le ensuite comme référence.

Les futurs tests utilisant les mêmes entrées xml peuvent faire une comparaison de fichiers binaires avec la référence.

Si une comparaison au niveau du fichier n'est pas satisfaisante, affichez le PDF à la fin du test et prenez des captures d'écran, puis comparez le test automatisé aux captures d'écran de référence.

Normalement, dans un cas comme celui-ci, vous résumez tout ce que vous ne pouvez pas tester derrière une implémentation que vous pouvez utiliser avec une interface. Je vais juste faire quelque chose de stupide comme PDF Builder car cela semble raisonnable.

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

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

Vous pouvez ensuite vous moquer de IPdfBuilder dans vos tests pour faire ce que vous voulez. Cela signifie souvent que vous devez commencer à utiliser un conteneur IoC ( /programming/871405/why-do-i-need-an-ioc-container-as-opposed-to-straightforward-di-code et /programming/21288/which-net-dependency-injection-frameworks-are-worth-looking-into comme point de départ) si vous n'en utilisez pas maintenant.

Et les tests qui ne sont pas des tests unitaires sont souvent appelés tests d'intégration. Les tests d'intégration compliqués n'en valent souvent pas la peine, vous devez donc simplement résumer cette partie et réduire la quantité de logique métier dans cette abstraction afin de pouvoir la tester dans un test unitaire.

Faites-moi savoir si ce n'est pas totalement clair.

J'ai construit quelque chose de très similaire il y a quelque temps et j'ai simplement utilisé des tests visuels de base. Les tests ne doivent pas être automatisés, il n'y a donc rien de mal à simplement rechercher un résultat attendu (évidemment, dans une variété de situations prédéterminées). Souvent, une image vaut mille tests en ce qui concerne les visuels . J'utilise intensivement les tests unitaires automatisés, mais je pense que certaines personnes peuvent être un peu emportées lorsqu'elles se lancent dans les tests GUI, ou n'importe quoi à mon humble avis. Avec certains produits, je reconnais que cette approche "assez bonne" ne sera pas suffisante donc YMMV.

Je serais cependant un peu inquiet des externalités immuables. Cela peut être un signe de couplage serré, ce qui est bon à éviter en règle générale, mais je ne spéculerai pas trop sur votre code à cet égard sans plus de détails.