2

J'ai beaucoup de mal à maintenir un site Web en ce moment. Le plus souvent, les choses finiraient par se casser après quelques mises à jour. Ce site a été créé par deux développeurs de notre équipe et m'a été transmis. Je me demandais si ce serait bien d'aller avec des tests unitaires et des tests d'acceptation étant donné que je suis à mi-chemin du projet.Mise en œuvre des tests d'unité et d'acceptation à mi-parcours d'un projet

Est-ce que cela prendrait beaucoup de temps à écrire des tests maintenant? Sera-t-il pratique ou existe-t-il d'autres méthodes de test pour cela?

Répondre

3

Il n'est jamais trop tôt pour introduire des tests et plus tôt vous le ferez, plus tôt vous commencerez à trouver les bogues. Je commencerais par tester à partir de deux points de vue différents. Tout d'abord, si vous avez des classes java assez autonomes utilisées pour des choses comme la logique métier et le traitement de données, je commencerais à créer des tests JUnit pour eux afin de résoudre les problèmes de code interne.

Deuxièmement, je voudrais créer des tests pour les cas d'utilisation spécifiés par l'entreprise. Ceux-ci seraient très probablement faits dans quelque chose comme Selenium parce que vous voulez que le test suive les interactions avec le site Web tel que spécifié par les cas d'utilisation. Laissez le Nitty Gritty aux tests JUnit dans les coulisses. Ce sont les confirmations de haut niveau de la fonctionnalité. Tout cela prendra du temps et il est peu probable que la direction vous permettra de ne faire que des tests pendant quelques semaines ou plus. Au lieu de cela, la façon la plus probable de la gérer est de le faire au fur et à mesure. Remplissez vos citations de temps pour les corrections et les nouvelles fonctionnalités pour permettre d'écrire les tests. Rappelez-vous que les tests d'écriture peuvent prendre 50% ou plus du temps, surtout lorsque vous commencez à les remplir. Le temps s'économisera un peu lorsque vous aurez un large éventail de suites, mais même alors, certains tests sont plus difficiles à écrire que le code. Mais ils en valent la peine.

+0

Aussi, n'essayez même pas de tout tester; Au lieu de cela, créez votre suite de tests au fur et à mesure. Concentrez-vous sur les bogues existants (écrivez un test qui échoue, puis passez le test) et sur les sections du code dont vous vous méfiez. D'accord, EXTRA suspect de. –

0

Je suis d'accord avec Derek. Jamais trop tard. Créez le cadre pour vos tests. Probablement un projet pour les tests d'intégration, un pour les tests unitaires. En fin de journée, concentrez-vous sur les tests d'intégration qui vous permettront de tester la solution avant les déploiements. Vous en tirerez rapidement profit. Au fur et à mesure que les bugs sont levés, cela vous donnera également l'infrastructure pour les reproduire plus facilement et créer des correctifs plus rapidement.