Si le langage en est capable, il peut tester une partie du contrat statiquement:
Dans le cas de C++, langage que je connais le mieux, on peut par exemple utiliser le prototype pour dire que la méthode ne modifieras pas la classe, que tel paramètre est un paramètre d'entrée (passage par valeur ou en spécifiant const), d'entrée/sortie (passage de référence), ou juste de sortie (valeur de retour. Si on en veut plusieurs, on peut utiliser un tuple, mais perso je ne suis pas trop fan des tuple donc je préfère utiliser un paramètre normal avec une référence) et bien entendu, imposer le type.
Mais il est évident que tu ne peux pas vérifier que x>0 à la compilation… (quoique, si x est calculable à la compilation, C++11 nous a offert quelques outils pour ça)
En fait, je ne pense pas qu'il soit logique d'opposer les deux types de programmation: un contrat bien établi permet d'écrire des tests plus facilement, avec en plus la possibilité d'instrumenter le code en interne, ce qui peut rendre les bugs plus simples à reporter pour l'utilisateur.
J'ai encore pas mal de mauvaises pratiques, héritées de mon auto apprentissage et des cours que j'ai eus (il faut dire ce qui est), donc j'avoue avoir beaucoup de mal à écrire de tests unitaires quand je bosse sur mes projets persos. Au boulot, vue la tronche de l'environnement que j'ai eu la "chance" d'utiliser, je n'ai pas vraiment essayé… (Déjà si on pouvait commencer par clarifier le workflow, et utiliser un vrai VCS, ce serait un net progrès… m'en fout, dans 2 mois je me casse)
Après, comme je l'ai dis, je suis loin d'être expert dans le domaine de la prog par contrat, alors ma vision est peut-être très limitée. Le document qui m'a fait découvrir le concept est ici
[^] # prog par contrat
Posté par freem . En réponse au journal Chiselapp ferme ses portes. Évalué à 1.
Si le langage en est capable, il peut tester une partie du contrat statiquement:
Dans le cas de C++, langage que je connais le mieux, on peut par exemple utiliser le prototype pour dire que la méthode ne modifieras pas la classe, que tel paramètre est un paramètre d'entrée (passage par valeur ou en spécifiant const), d'entrée/sortie (passage de référence), ou juste de sortie (valeur de retour. Si on en veut plusieurs, on peut utiliser un tuple, mais perso je ne suis pas trop fan des tuple donc je préfère utiliser un paramètre normal avec une référence) et bien entendu, imposer le type.
Mais il est évident que tu ne peux pas vérifier que x>0 à la compilation… (quoique, si x est calculable à la compilation, C++11 nous a offert quelques outils pour ça)
En fait, je ne pense pas qu'il soit logique d'opposer les deux types de programmation: un contrat bien établi permet d'écrire des tests plus facilement, avec en plus la possibilité d'instrumenter le code en interne, ce qui peut rendre les bugs plus simples à reporter pour l'utilisateur.
J'ai encore pas mal de mauvaises pratiques, héritées de mon auto apprentissage et des cours que j'ai eus (il faut dire ce qui est), donc j'avoue avoir beaucoup de mal à écrire de tests unitaires quand je bosse sur mes projets persos. Au boulot, vue la tronche de l'environnement que j'ai eu la "chance" d'utiliser, je n'ai pas vraiment essayé… (Déjà si on pouvait commencer par clarifier le workflow, et utiliser un vrai VCS, ce serait un net progrès… m'en fout, dans 2 mois je me casse)
Après, comme je l'ai dis, je suis loin d'être expert dans le domaine de la prog par contrat, alors ma vision est peut-être très limitée. Le document qui m'a fait découvrir le concept est ici