Bonjour à tous,
Je voudrais savoir s'il est possible de faire des tests d'intégration et de non-régression avec delphi ?
Merci beaucoup
Version imprimable
Bonjour à tous,
Je voudrais savoir s'il est possible de faire des tests d'intégration et de non-régression avec delphi ?
Merci beaucoup
Bonjour,
pour moi c'est vague comme question
Comme nous n'avons certainement pas les mêmes cadres de référence, il faudrait être plus explicite sur ces termesCitation:
tests d'intégration et de non-régression
Quels sont les autres moyen de tester une application ? Mis à part les tests unitaire.Citation:
Envoyé par SergioMaster
payeur un testeur humain :) c'est super bien en fait, ça permet de créer un emploi et quand on comprend pas le cas de test, on peut lui demander comment il a fait pour le produire :)Citation:
Envoyé par zohra051
Je ne connais que 3 méthodes :
- Tester toutes les configurations connues (envisagées par les développeurs). L'inconvénient est qu'on reste sur l'hypothèse (Utopique) d'avoir pensé à tout...
- L'utilisation d'un testeur externe qui n'a pas été trop "imprégné" par le développement. Le M. "Naif" qui peut faire des essais imprévisibles, voire incohérents pour les développeurs. Les M. "Schcoumoune" qui une bonne dose de malchance sont remarquables dans cet exercice :)
- Le générateur aléatoire (la ptite souris sur le clavier), avec l'inconvénient, comme le dit Paul, de ne pas pouvoir expliquer comment il a provoqué tel ou tel défaut.
Evidemment, pour faire moderne, tout ça va peu à peu, être infiltré par l'IA. Le concept de BA (Bug Artificiel, ou Bêtise Artificielle) va bientôt envahir le monde. Puisqu'on apprend l'intelligence à nos machines, l'art et la créativité, pourquoi ne pas ne pas leur offrir de la folie, de la bêtise...de la méchanceté ? :ptdr:
Belle journée à tous,
les tests d'intégration peuvent être réalisé avec DUnit, c'est juste que cela devient complexe car il faut généralement beaucoup de donnée pour tester un module entier au lieu de se limiter à un test unitaire d'une fonction.
les tests de non-régression avec delphi ?
En fait, si l'on a écrit les test unitaires, test d'intégration de la version N, ils sont justement là pour garantir ensuite tant que la fonction\le module n'évolue pas de fonctionner tel prévu en N+1, N+2 ...
En parallèle, un outil tel que Ranorex distribué par IDERA la maison mère d'Embarcadero
Evidemment comme le dit Paul Toth, tout cela c'est du temps
- Le Test Unitaire doit être écrit AVANT la fonction, si possible par un autre développeur
- Le Test d'Intégration doit être imaginé dès le modèle de donnée disponible et une fois un module suffisamment avancé, encore une fois par un autre développeur
- Le Scenario Ranorex demande évidemment du temps pour sa construction
Tout cela n'a finalement rien à avoir avec Delphi, c'est juste de la méthodologie et il ne faut pas hésiter à regarder ce qui existe dans d'autres langages.
D'ailleurs, une application multi-tiers est plus facile à tester en séparant une application C\S en deux applications, une Serveur REST par exemple et un Client (VCL, FMX, Web), évidemment, cela demande plus de développeurs de réaliser un développement qui se fait en deux temps.
Ainsi on peut réaliser un grand nombre de Tests unitaires sur les fonctions exposées par le Server REST et ainsi vérifier que les données retournés sont bonnes.
Ensuite utiliser Ranorex ou un autre outil de test pour GUI où l'on sait déjà quelles API REST sont validées et celles qui ne le sont pas.
il ne faut pas oublié aussi un bias du test unitaire, il est écrit pour vérifier que la fonction répond bien à ce qu'on attends d'elle. Du coup le test permet au départ de s'assurer que le code n'est pas incohérent. J'en fais souvent dans mes unités comme ici.
et justement, les bugs apparaissent en général quand le code est invoqué dans un contexte qu'on avait pas prévu, et c'est là que le monsieur "Schcoumoune" est intéressant, car il se fiche bien de savoir comme a été conçu le logiciel, il n'en fait qu'à sa tête et fait des choses que le programmeur n'a même pas imaginé.
une fois le bug identifié, on crée un nouveau test unitaire qui le met en valeur, et seulement après on le corrige...et avec tous les précédents tests, il permet de s'assurer que CE bug ne reviendra plus jamais sans qu'on s'en aperçoive (test de non régression).
Quand on a à sa disposition un testeur, il peut:
- tenter de planter les nouvelles fonctionnalités pour trouver des failles
- tenter de reproduire les précédents plantages pour s'assurer qu'ils sont bien corrigés
il est en quelque sorte un test unitaire intelligent qui est capable de savoir si les tests sont toujours d'actualité ou non (évolution du logiciel)....après moi je trouve que c'est un boulot chiant, mais je connaissais des gens à qui ça convenait parfaitement car il y a une petite notion de "hacker" dans le sens où on cherche les failles du logiciel, et pour le reste ça ne demande pas trop de réflexion, juste un peu de méthode.
l'autre avantage du testeur, c'est qu'il est là pour identifier LE cas où le bug ce produit, et ça c'est très précieux pour le développeur qui peut directement passer en debug sur la partie du code concernée.