Application de la séquence d'exécution de code

Question

Parfois, vous n'avez qu'une liste d'opérations qui doivent être exécutées dans un ordre déterminé, comme lors de l'implémentation d'un diagramme de séquence. Quelles sont les meilleures façons d'appliquer l'ordre d'exécution du code, pour empêcher le refactoring d'introduire des bugs subtils à travers un changement de séquence?

Supposons que les tests unitaires existants n'attrapent aucun problème causé par le changement de l'ordre d'exécution de foo() et bar() dans ce qui suit.

Quelques-unes des méthodes que je l'ai vu et utilisé:

1. Commentaires (associant des personnes de lecture & leur compréhension):

   // do this
foo();
// then this
bar();

2. grammaire Courant (pour que le code soit plus proche de l'anglais et décourage le refactoring gratuit):

   obj
.Do
.foo()
.Then
.bar();

3. variables d'état & rechignant (préciser aussi):

   foo_done=false;
if(foo()) foo_done=true;
if(foo_done) bar(); else throw_an_exception;

4. Regroupement des blocs logiques en fonctions:

   void foo_bar()
{
foo();
bar();
}

... et bien d'autres trop laid pour décrire (imbrication, les événements, les tableaux de pointeurs de fonction, les fonctions de nommage Begin(), Moyen() et End() ...) .

Y a-t-il des modèles mieux conçus pour faire ce genre de chose?

Answer 1

Je suis confus pour expliquer pourquoi l'ordre est significatif si les tests unitaires ne seraient pas les attraper, et les dépendances ne sont pas explicitement dans le code; cela implique que les effets secondaires sont une partie cruciale de l'opération de foo() et de bar(). Dans ce cas, la meilleure stratégie de conception serait de rendre ces effets secondaires explicites!

Answer 2

Vous écrivez des tests unitaires pour vérifier ce qui s'est passé (état, changement d'attributs) après avoir appelé une procédure, donc je ne pense pas que vous ayez besoin de vérifier si une méthode a été appelée ou non. De plus, si vous liez votre test à une méthode, plus tard, si vous changez votre système pour utiliser une autre méthode avec les mêmes effets de foo(), votre test échouera même si votre système fait les bonnes choses.