Je travaille avec le système suivant:
Network Data Feed -> Third Party Nio Library -> My Objects via adapter pattern
Nous avons récemment eu un problème concernant l’actualisation de la version de la bibliothèque que j’utilisais, ce qui a notamment provoqué la long
modification de l’ horodatage (renvoyé par la bibliothèque tierce ) de millisecondes après l’époque à des nanosecondes après l’époque.
Le problème:
Si j'écris des tests qui simulent les objets de la bibliothèque tierce, mon test sera faux si j'ai commis une erreur à propos des objets de la bibliothèque tierce. Par exemple, je ne savais pas que les horodatages changeaient la précision, ce qui nécessitait une modification du test unitaire, car ma maquette renvoyait les mauvaises données. Ce n'est pas un bug dans la bibliothèque , c'est parce que quelque chose dans la documentation m'a échappé.
Le problème est que je ne peux pas être sûr des données contenues dans ces structures de données car je ne peux pas en générer de vraies sans un véritable flux de données. Ces objets sont volumineux et compliqués et contiennent beaucoup de données différentes. La documentation de la bibliothèque tierce est médiocre.
La question:
Comment puis-je configurer mes tests pour tester ce comportement? Je ne suis pas sûr de pouvoir résoudre ce problème dans un test unitaire, car le test lui-même peut facilement être faux. De plus, le système intégré est volumineux et compliqué et il est facile de rater quelque chose. Par exemple, dans la situation ci-dessus, j’avais correctement ajusté la gestion de l’horodatage à plusieurs endroits, mais j’en ai manqué un. Le système semblait faire essentiellement les bons choix dans mon test d'intégration, mais lorsque je l'ai déployé en production (qui contient beaucoup plus de données), le problème est devenu évident.
Je n'ai pas de processus pour mes tests d'intégration pour le moment. Le test consiste essentiellement à: maintenir les tests unitaires correctement, ajouter d'autres tests en cas de défaillance, puis déployer sur mon serveur de test et s'assurer que les choses semblent saines, puis passer à la production. Ce problème d'horodatage a réussi les tests unitaires, car les modifications ont été créées, puis il a réussi le test d'intégration, car il ne posait aucun problème immédiat et évident. Je n'ai pas de département QA.
Timestamp
classe (contenant une représentation qu'ils veulent) et fournir des méthodes nommées ( .seconds()
, .milliseconds()
, .microseconds()
, .nanoseconds()
) et des constructeurs cours nommés. Ensuite, il n'y aurait pas eu de problèmes.