L'utilisation de valeurs aléatoires dans l'unité teste-t-elle une bonne pratique?
Après avoir travaillé dans des solutions complexes qui avaient des tests d'unités et un test d'intégration dans le pipeline CI/CD, je me rappelle avoir un temps difficile avec des tests qui ont échoué au hasard (soit en raison des valeurs aléatoires étant injectées, soit en raison de la nature asynchrable du processus testé - cela de temps à autre a abouti à une situation de course étrange). Quoi qu'il en soit, avoir ce comportement aléatoire dans le pipeline CI n'était pas une bonne expérience, nous ne pourrions jamais dire avec certitude que le changement qu'un développeur engagé a vraiment causé la question de la construction.
J'ai récemment été initié à la mise au point automatique, qui aide à la création de tests, en générant des valeurs de manière aléatoire - surprenant, j'étais le seul à ne pas avoir pensé que c'était une bonne idée de la présenter dans tous les tests de notre pipeline CI.
Je veux dire, je comprends des tests de fuzz, des tests de singe, etc. mais je crois que cela devrait être fait hors du pipeline CI/CD - qui est l'endroit où je veux assurer que mes exigences commerciales sont respectées en cas de solidité, solide et stricte à la Tests ponctuels. Des tests de comportement non linéaires tels que ceci (et le test de charge, la boîte noire, la pénétration, etc.) doivent être effectués en dehors du pipeline de construction - ou au moins ne doivent pas être directement liés aux modifications de code.
Si ces tests latéraux trouvent jamais un comportement qui n'est pas attendu, une solution doit être créée et un nouveau cas de test en béton et reproduit doit être ajouté pour éviter de revenir à l'état précédent.
Est-ce que je manque quelque chose?
Pour citer Autofixture:
"... Conçu pour minimiser la phase" Arrangement "de vos tests d'unités afin de maximiser la maintenabilité. Son objectif principal est de permettre aux développeurs de se concentrer sur ce qui est testé plutôt que de la configuration du scénario de test."
Je peux donc voir pourquoi vous ne voudriez pas de test tel que:
x = random int
actual = SquareRoot(x)
Assert(actual = x^2)
Vous voudriez explicitement tester des chiffres maximum int, négatifs, etc. et assurez-vous que le test est répétable.
Cependant, ce n'est pas ce que l'autofixe propose. Ils sont plus intéressés par des tests comme
x = new Customer
x.firstname = ...
x.lastname = ..
x.middlename = ...
x.Address = new Address()
x.Address.Street = ...
....
x.Account = new Accout()
...
etc
repo.Save(x)
actual = repo.Load(x.Id)
Assert(actual = x);
Vous pouvez maintenant constater que votre test est peu susceptible d'échouer par les valeurs que vous attribuez aux différents champs des clients et des sous-classes. Ce n'est pas vraiment ce que vous testez.
Mais! Il vous ferait économiser beaucoup de code de frappe et sans importance si vous pouvez auto-remplir tous ces champs.