La conception par contrat fonctionne-t-elle pour vous ?[fermé]

Question

Utilisez-vous le Design by Contract à titre professionnel ?Est-ce quelque chose que vous devez faire dès le début d’un projet, ou pouvez-vous changer de vitesse et commencer à l’intégrer dans votre cycle de vie de développement logiciel ?Selon vous, quels sont les avantages/inconvénients de l’approche de conception ?

Je suis tombé sur le Conception par contrat approche dans un cours d’études supérieures.Dans le cadre universitaire, cela semblait être une technique très utile.Mais je n'utilise actuellement pas Design by Contract de manière professionnelle et je ne connais aucun autre développeur qui l'utilise.Ce serait bien d'entendre parler de son utilisation réelle de la part de la foule SO.

Answer 1

Je ne saurais trop le recommander.C'est particulièrement intéressant si vous disposez d'une suite qui prend en charge les spécifications contractuelles de la documentation en ligne, comme ceci :

// @returns null iff x = 0
public foo(int x) {
  ...
}

et les transforme en tests unitaires générés, comme ceci :

public test_foo_returns_null_iff_x_equals_0() {
  assertNull foo(0);
}

De cette façon, vous pouvez réellement voir les tests que vous exécutez, mais ils sont générés automatiquement.Soit dit en passant, les tests générés ne doivent pas être archivés dans le contrôle de code source.

Answer 2

Vous appréciez vraiment la conception par contrat lorsque vous disposez d’une interface entre des applications qui doivent communiquer entre elles.

Sans contrat, cette situation devient rapidement un jeu de reproche au tennis.Les équipes continuent de lancer des accusations et d’énormes pertes de temps.

Avec un contrat, le blâme est clair.

L'appelant a-t-il satisfait aux conditions préalables ?Sinon, l'équipe client doit le réparer.

Étant donné une demande valide, le destinataire a-t-il satisfait aux conditions du poste ?Sinon, l'équipe du serveur doit résoudre ce problème.

Les deux parties ont-elles respecté le contrat, mais le résultat n'est pas satisfaisant ?Le contrat est insuffisant et le problème doit être intensifié.

Pour cela, vous n'avez pas besoin que les contrats soient mis en œuvre sous forme d'assertions, il vous suffit de vous assurer qu'ils sont documentés et acceptés par toutes les parties.

Answer 3

Si vous examinez STL, boost, MFC, ATL et de nombreux projets open source, vous pouvez voir qu'il y a tellement d'instructions ASSERTION et cela permet au projet d'aller plus loin en toute sécurité.

Conception par contrat !Cela fonctionne vraiment dans un produit réel.

Answer 4

Frank Krueger écrit :

Gaïus :Une exception Null Pointer est générée automatiquement par le runtime, il n'y a aucun avantage à tester ces éléments dans le prologue de la fonction.

J'ai deux réponses à cela :

1. Null n'était qu'un exemple.Pour square(x), je voudrais tester que la racine carrée du résultat est (approximativement) la valeur du paramètre.Pour les setters, je voudrais tester que la valeur a réellement changé.Pour les opérations atomiques, je voudrais vérifier que toutes les opérations des composants ont réussi ou toutes ont échoué (en réalité un test de réussite et n tests d'échec).Pour les méthodes d'usine dans les langages faiblement typés, je souhaite vérifier que le bon type d'objet est renvoyé.La liste se rallonge de plus en plus.Fondamentalement, tout ce qui peut être testé dans une seule ligne de code est un très bon candidat pour un contrat de code dans un commentaire de prologue.

2. Je ne suis pas d'accord avec le fait que vous ne devriez pas tester les choses car elles génèrent des exceptions d'exécution.Si quoi que ce soit, vous devrait testez les éléments susceptibles de générer des exceptions d'exécution.J'aime les exceptions d'exécution car elles rendent le système échouer rapidement, ce qui facilite le débogage.Mais le null dans l'exemple, il s'agissait d'une valeur de résultat pour une entrée possible.Il y a un argument à faire valoir pour ne jamais revenir null, mais si vous le souhaitez, vous devriez le tester.

Answer 5

Il est absolument insensé de ne pas concevoir par contrat lorsque vous faites quoi que ce soit dans un domaine SOA, et c'est toujours utile si vous travaillez sur tout type de travail modulaire, dans lequel des éléments peuvent être échangés plus tard, surtout si des boîtes noires sont impliquées. .

Answer 6

Au lieu de systèmes de caractères plus expressifs, j'utiliserais absolument la conception par contrat sur des projets de qualité militaire.

Pour les langages faiblement typés ou à portée dynamique (PHP, JavaScript), les contrats fonctionnels sont également très pratiques.

Pour tout le reste, je le mettrais de côté et m'appuierais sur les bêta-testeurs et les tests unitaires.

Gaïus:Une exception Null Pointer est générée automatiquement par le runtime, il n'y a aucun avantage à tester ces éléments dans le prologue de la fonction.Si vous êtes plus intéressé par la documentation, j'utiliserais des annotations qui peuvent être utilisées avec des analyseurs statiques et autres (pour m'assurer que le code ne casse pas vos annotations par exemple).

Un système de type plus fort couplé à la conception par contrat semble être la voie à suivre.Jeter un coup d'œil à Numéro de spécification à titre d'exemple:

Le langage de programmation Spec#.Spec # est une extension de la langue orientée objet C #.Il étend le système de type pour inclure des types non nuls et des exceptions vérifiées.Il fournit des contrats de méthode sous forme de pré- et de post-climinages ainsi que des invariants d'objets.

Answer 7

Les tests unitaires et la conception par contrat sont des approches de test précieuses d'après mon expérience.

J'ai essayé d'utiliser la conception par contrat dans un cadre de tests automatiques de système et mon expérience est que cela offre une flexibilité et des possibilités difficiles à obtenir par les tests unitaires.Par exemple, il est possible d'exécuter une séquence plus longue et de vérifier que les temps de réponse sont dans les limites chaque fois qu'une action est exécutée.

En regardant les présentations à InfoQ, il apparaît que le Design by contract est un complément précieux aux tests unitaires conventionnels dans la phase d'intégration des composants.Par exemple, il est possible de créer d'abord une interface simulée, puis d'utiliser le composant après - ou lorsqu'une nouvelle version d'un composant est publiée.

Je n'ai pas trouvé de boîte à outils couvrant toutes mes exigences de conception à concevoir par tests de contrat sur la plate-forme .NET / Microsoft.

Answer 8

En fait, je n'utilise pas Design by Contract au quotidien.Je sais cependant qu'il a été intégré au D langue, en tant que partie de la langue.

Answer 9

Oui!En fait, il y a quelques années, j'ai conçu un petit framework pour la validation des arguments.Je faisais un projet SOA, dans lequel les différents systèmes back-end effectuaient toutes sortes de validations et de vérifications.Mais pour augmenter les temps de réponse (dans les cas où l'entrée n'était pas valide, et réduire la charge de ces systèmes back-end), nous avons commencé à valider les paramètres d'entrée des services fournis.Non seulement pour Not Null, mais aussi pour les modèles String.Ou des valeurs provenant d’ensembles.Et aussi les cas où les paramètres avaient des dépendances entre eux.

Maintenant, je me rends compte que nous avions mis en place à cette époque un petit cadre de conception par contrat :)

Voici le lien pour ceux qui sont intéressés par le petit Validation des arguments Java cadre.Qui est implémenté sous forme de solution Java simple.

Answer 10

Je trouve révélateur que le langage de programmation Go n'a aucune construction permettant la conception par contrat.panique/différer/récupérer ne sont pas exactement cela, car la logique de report et de récupération permet d'ignorer la panique, IOW d'ignorer le contrat rompu.Ce qu’il faut au moins, c’est une forme de panique irrécupérable, ce qui est vraiment vrai.Ou, au mieux, un support linguistique direct des constructions de conception par contrat (conditions préalables et postérieures, implémentation et invariants de classe).Mais étant donné la détermination des puristes du langage à la barre du navire Go, je ne change rien à tout cela.

On peut implémenter un comportement de type assert en vérifiant l'erreur d'assertion spéciale dans la fonction de dernier report dans la fonction de panique et en appelant runtime.Breakpoint() pour vider la pile pendant la récupération.Pour être affirmé, ce comportement doit être conditionnel.Bien sûr, cette approche s'effondre lorsqu'une nouvelle fonction de report est ajoutée après celle qui fait l'assertion.Ce qui se produira dans un grand projet exactement au mauvais moment, ce qui entraînera des bugs manqués.

Ce que je veux dire, c'est que cette assertion est utile à bien des égards que devoir danser autour d'elle peut être un casse-tête.