Vaut-il la peine d'essayer de rédiger des tests pour le site le plus étroitement couplé au monde?

Question

Imaginez que 90% de votre travail est simplement pour le triage des questions sur un très massif, très cassé site web. Imaginez que ce site est écrit dans les plus étroitement associés, moins cohérent code PHP que vous avez jamais vu, le type de code à ajouter les développeurs à l'origine de votre "claque sur la vue" liste. Imaginez que cette application web est composé de 4 éléments disparates (1 commerciale, 2 "redéfini", et 1 personnalisé) et une merde tonnes de virtuel ruban adhésif et les cales. Imaginez qu'il contient le type de pratiques de programmation dans lequel les principaux composants du site web réellement compter sur des choses qui ne fonctionnent PAS correctement, et la fixation de ces choses cassées généralement des pauses d'autres choses. Imaginez que vous savez de trop nombreuses mauvaises expériences que la modification de l'une apparence anodins partie du site web, tels que la division d'un champ "nom" en deux "premier" et "dernier" des champs, permettra d'amener le site à ses genoux et nécessitent des heures de restaurations, des fusions et des correctifs. Imaginez plaidant avec le client pour les années à juste fossé le code et tout recommencer mais étant rencontré au niveau de l'Entreprise désespoir et de la main-essorage. Alors imaginez-vous le plus vite possible/les billets d'URGENCE à mettre en œuvre de nouvelles fonctionnalités dans un autre site web serait de prendre 4 heures, mais vous le savez mieux avec ce site, donc vous citer de 40 heures, puis le coup, de même que le projet de loi 80 heures, mais c'est OK parce que le client est utilisé pour que, avec leur site web.

Voici quelques autres choses que vous devriez aussi imaginer:

• il n'existe pas de tests en ce moment
• il y a googleteen différentes couches de connexions. Certains clients ont en fait 3 comptes différents pour les différentes sections du site
• quand je dis "couplés", je veux dire les boucles d'inclure ou d'exiger des déclarations serait probablement la carte comme un noeud celtique
• quand je dis "moins cohérent", je veux dire des choses est organisé un peu comme MVC, mais ce n'est pas vraiment MVC. Dans certains cas, il peut vous prendre plusieurs heures juste pour savoir comment UN URI est mappé sur le fichier B
• l'INTERFACE utilisateur a été écrit comme "discret" et "inaccessible" ont été les maîtres-mots de la journée

En imaginant tout ce que, est-il même la peine d'essayer d'atteindre un niveau modéré de la couverture de test? Ou devriez-vous, dans cet imaginaire de scénario, juste continuer à faire du mieux que vous pouvez avec ce que vous avez été donné et en espérant, priant, peut-être même de sacrifice, que le client conviennent à une réécriture de l'un de ces jours et vous pouvez commencer à écrire des tests?

ADDENDUM

Puisque beaucoup d'entre vous en fait: j'ai abordé la possibilité d'une ré-écrire à chaque fois que je ai eu à ce jour. Le marketing de gens qui travaillent avec moi savent que leur code est de la merde, et ils savent que c'est la faute de "l'offre la plus basse" entreprise, ils sont allés à l'origine. J'ai probablement dépassé mes limites en tant qu'entrepreneur, en soulignant qu'ils passent une merde tonne d'argent sur moi pour fournir des soins palliatifs pour le site, ainsi que par le réaménagement de zéro, ils allaient voir un retour sur investissement très rapidement. J'ai aussi dit que je refuse de réécrire le site, car il n'a pas vraiment faire ce qu'ils veulent à faire de toute façon. Le plan est de le réécrire BDD style, mais aussi obtenir tous les acteurs clés dans un endroit qui est difficile, et je ne suis toujours pas sûr qu'ils savent ce dont ils ont besoin. En tout cas, je m'attends à ce que ce soit Un Très Gros Projet.

Merci pour tous les commentaires jusqu'à présent!

Answer 1

Vous aurez probablement pas obtenir une couverture complète pour un certain temps. Mais vous pouvez écrire des tests pour le nouveau code/fonctionnalités à mettre en œuvre. Commencer petit. Ne pas essayer de faire tout à la fois.

Et peut-être le livre "Travailler efficacement avec les Legacy Code" est intéressant à lire?

Modifier

Je voudrais également recommander de regarder cette présentation de l'Oncle Bob qui touche à ce scénario et la façon de transformer un mauvais code de base, dans une bonne aide "Élargissement Progressif"

Edit 2

Commencez par trouver tous les contenus de fonctions. Les fonctions qui ne référence rien, mais les arguments passés en. Déplacer et de les organiser dans des classes d'assistance. C'est probablement que temporaire, comme beaucoup se retrouvent dans des classes différentes plus tard, mais cela permet d'identifier un peu de code dupliqué, et de commencer les choses organisées. Ensuite, regardez comment ils sont utilisés, écrire des tests sur la base de ces utilisations. Et vous tape dans le dos. Vous avez commencé à faire de votre code plus facile à maintenir.

Edit 3

Avec le bon timing InfoQ viens de poster un autre article Comment le Faire à Grande Échelle Refactoring qui est précisément ce genre de chose, et un autre, plus ancien article intitulé Refactoriser ou Réécriture? et il y a des techniques comme le Mikado Méthode où vous devez réaliser que vous ne pouvez pas toujours faire le déménagement vous le souhaitez en une seule étape, vous avez à prendre d'autres coups à l'installation et à réaliser votre objectif.

Answer 2

Absolument pas.

Si vous dire que plusieurs choses s'appuyer sur d'autres choses plus précisément ne fonctionne pas alors comment pouvez-vous même de commencer à le tester?

Personnellement, je dirais que de la ferraille et recommencer. Quatre heures de fonctionnalités qui prennent 80? J'espère que c'est une exagération. Les maux de tête que vous devez avoir.

Je voudrais commencer par une très ferme proposition de ré-écrire le code de base. Essorage clients doit être dit sans détour, la vérité, à certains moments. Combien d'autres les développeurs de travail avec une fracture de la base? Faire quelques jolies coût / bénéfice des graphiques.

Par tous les moyens d'écrire des tests pour le code que vous écrivez. Ne négligez pas que. Je le dis, je ne voudrais pas essayer d'écrire des tests sur le code existant de la base.

Answer 3

Lui donner un aller

L'écriture de tests vous permet de refactoriser. Si vous écrivez vos tests à un haut niveau suffisant, vous pouvez gérer pour le faire de sorte que vous pouvez restructurer sans avoir à ré-écrire les tests à chaque fois.

C'est au moins la peine de un aller, sur une petite partie du site (je sais que vous ne serez pas en mesure d'isoler entièrement toute la partie, mais vous pouvez toujours partie de la cible).

Peut-être fixez-vous un budget-temps (c'est à vous de déterminer ce qui est abordable/vaut), puis avoir un aller avec quelques essais et quelques refactorings. Si cela ne fonctionne pas, faire reculer. Si elle le fait, porter sur.

Bonne chance!

Answer 4

Tout d'abord, si votre client est à utiliser pour vos estimations étant la moitié de ce qu'il faut, fixer vos estimations! Il est beau le client est " OK " avec les estimations étant de les désactiver, mais il est essentiel que vous obtenez vos estimations, plus en ligne avec les efforts réellement nécessaire. Sans que, de ce que le client aurait jamais consentir à une modification majeure, et encore moins d'une réécriture. Donc obtenir un peu d'histoire de droit avec les estimations, puis passer à retravailler le projet.

Comme pour l'écriture des tests. C'est encore plus vital pour ce que vous décrivez que pour un vert-projet de terrain. Dans chaque morceau de code que vous touchez demandez-vous si il est possible de dissocier le comportement que devrait être là depuis le problème est là. Écrire le code de la façon dont il devrait être (avec tests), puis ajouter une couche d'abstraction pour en faire la manière il ne l'est actuellement (et test de trop!). Vous vous sentirez comme votre ajouter à la pagaille, et vous serez -- mais lentement, au fil du temps, les tests, vous serez en confiance dans ces domaines.

Si c'est quelque chose comme ce que j'ai du faire avec, il sera de l'ordre de tirer une seule méthode dans une classe d'assistance et de correction dans le code existant, ne semble guère la peine, mais ça ne payer chaque fois que vous avez de toucher cette partie de l'appareil de nouveau. Comme ils disent - "c'est mieux que vous l'avez trouvé" et vous commencerez à le trouver en meilleure forme à chaque fois que vous revenez à lui. Les Tests sont le meilleur moyen de laisser mieux que vous l'avez trouvé.

Mais sérieusement, il faut que le client confiance dans l'exactitude de vos calculs est nécessaire avant de pouvoir être pleinement confiance en votre capacité à gérer un surplus de travail.

Answer 5

Absolument écrire des tests. Surtout dans un contexte de pénurie couplé à l'environnement les tests vont être encore plus critique (depuis une correction de bug dans un domaine peuvent considérablement affecter d'autres régions en raison du couplage).

Maintenant, sachez que ce ne sera probablement pas une tâche triviale. Afin d'écrire des tests, vous aurez besoin de modifier le code pour être testable. Pour modifier le code, vous avez besoin d'avoir des tests. Si vous êtes pris dans un cycle de dépendance...

Cependant, regardez les avantages potentiels. Cela devrait vous dire si c'est vraiment la peine ou non.

Si vous ne commencer, commencer petit. Choisissez-en un petit morceau qui ressemble vaguement reliés entre eux, et de le tester. Puis de trouver quelque chose d'autre qui n'est pas que emmêlés. Test de tous les plus lâches des morceaux (les fruits mûrs). Ensuite, une fois que vous obtenez à la très serrée des pièces, vous serez tous les deux plus à l'aise et (espérons-le) plus un aperçu de ce qui vous avez vraiment besoin de le faire.

Rappelez-vous, vous n'avez pas besoin de couverture de 100% pour en récolter les bénéfices. Chaque test ajoute du sens...