Discussion :

[JackIsJack]

Bonjour à tous,

Je me pose une question sur l'usage de Visual Studio (2013) dans un contexte professionnel.

Le sujet, c'est les projets de type "Test unitaire", que l'on peut ajouter à sa solution dans Visual Studio.



Je pense avoir compris le principe : Avoir un projet "de test' au sein de sa solution, puis écrire des procédure dans ce projet de test qui vont pouvoir être exécuté en masse par Visual Studio, "à la volée" (sans que le programme principale tourne) ; en retournant leurs résultats à la fin, et de façon bien visuelle.

Question : Utilisez-vous cette fonctionnalité dans votre contexte professionnel ?
Si non, pourquoi ?

J'ai téléchargé certains projets open-source sur GitHub, sans avoir pu constater que de tels projets 'de test' existent.
Par ailleurs, dans la boîte où je travaille, cela m'étonnerait que ça soit utilisé (je demanderai) au vue des System.Exceptions que se prends l'utilisateur parfois dans des cas pourtant très standard.

Merci pour toutes informations,

[J@ckHerror]

Bonjour,

Je n'ai utilisé les tests unitaires que dans le cadre d'un seul projet. L'idée était on le fait correctement pour voir ce que donne les tests unitaires... Et au final à la fin du projet les tests avaient été abandonnés...
Je ne suis du coup pas du tout un pro des tests unitaires, cela dit, de mon point de vue, ça amène une quantité de travail supplémentaire énorme. L'idée est de tester ta couche métier (peut être que les autres couches peuvent être testées aussi, mais dans mon cas nous étions resté sur les tests des la couche métier), il faut donc écrire plusieurs tests par méthodes/fonctions pour être exhaustifs et modifier les tests quand on modifie le métier, c'est donc assez lourd. Niveau organisation ça oblige à travailler en équipe (sa par contre c'est bien ) car écrire du métier et les tests qui vont avec, ça manque d'objectivité, l'idéal est qu'un dev développe le métier et un les tests, et la semaine d'après on inverse (je crois que c'est d'ailleurs ce que conseille les pro de l'organisation de projet de dev).
Donc pour moi le plus gros problème que cela avait amené au projet c'était une énorme inertie de développement, et dès qu'il a fallut accélérer le développement pour ajouter des fonctionnalités pas prévues et rester à peu près dans les clous niveau timing on a arrêté les tests pour pouvoir accélérer...

Je pense donc que les tests on un intérêt uniquement sur de gros projet qui ont donc beaucoup de ressource et/ou que le projet demande une rigueur accrue (développement de programme de guidage de missiles, de surveillance de centrale ... bref partout où un bug est dramatique).
Pour des plus petit projet une bonne période de test avec un utilisateur lambda en fin de développement suffit pour bien des projets auquel j'ai participé.

Je rajouterais que c'était la mode il y a quelques années et que la mode a changé.

Cela dit vu mon expérience au final assez négative j'attends de voir ce qu'en dirons ceux qui ont plutôt une idée positive de la chose, car comme je te l'ai dis mon expérience provient d'un projet 'de test' et je ne suis pas allé au bout donc forcement j'aurais du mal à être positif.


J@ck.

[JackIsJack]

Hello Jack,

Merci pour ce retour d'expérience !

Cela confirme mon intuition que ce n'est pas "hyper" répandue.

Du coup, je m'interroge sur la façon dont les développeurs pro testent leur code !

Dois-je comprendre qu'un développeur pro va pouvoir écrire son code (sans jamais l'exécuter) et c'est seulement lors de la phase de test métier qu'il s’apercevra des anomalies ?

Je suis développeur amateur et, jusqu'ici je teste chacune de mes lignes de code dans le sens où je lance mon programme en permanence pour m'assurer que les lignes que j'ai tapé font bien ce que je souhaites.

Dans ma procédure Main(), je met souvent une procedure TestUnitaire() tout au début, qui va me servir un peu de 'poubelle à code'. Je vais y tester tous les bouts de mon programme de façon rapide (sans avoir besoin de passer l'interface, et de cliquer manuellement). Et quand livre mon programme, je retire cette procedure 'TestUnitaire()'. (Elle n'est utile que pour moi).

C'est délirant comme pratique ? Il y a mieux ?

[J@ckHerror]

Re,

Du coup, je m'interroge sur la façon dont les développeurs pro testent leur code !

Comme je te l'ai dis au final je n'ai pas vraiment d'expérience sur les tests unitaires. Pour ma part je testes "le produit finit" et dans la mesure du possible je demande à un utilisateur de réaliser des tests aussi pour moi, d'expérience je peux te dire qu'un développeur est souvent le moins bien placé pour tester l'appli qu'il vient de développer. Typiquement pendant une semaine suivant la livraison d'un module ou d'une appli, j'installe l'appli sur un seul poste et je log tout. L'utilisateur étant chargé de faire un max de test et d'éprouver l'appli (un bug trouvé = un café ! ça marche pas mal )

Dois-je comprendre qu'un développeur pro va pouvoir écrire son code (sans jamais l'exécuter) et c'est seulement lors de la phase de test métier qu'il s’apercevra des anomalies ?

Je n'ai jamais participé a de gros gros projet ou plusieurs équipes sont chargées de développer plusieurs modulse qui devront ensuite former une appli (et jamais de SSII ) du coup je ne sais pas vraiment comment cela ce passe, mais je pense que oui dans ce genre de cas le dev sera obliger de soit faire des tests unitaires soit un peu à ta façon de se faire un applicatif de test pour tester son module ... je ne sais ! peut être qu'un lecteur avec ce genre d'expérience nous en dira plus ...

Je suis développeur amateur et, jusqu'ici je teste chacune de mes lignes de code dans le sens où je lance mon programme en permanence pour m'assurer que les lignes que j'ai tapé font bien ce que je souhaites.

de mon point de vue être rigoureux n'est pas un défaut !

Dans ma procédure Main(), je met souvent une procedure TestUnitaire() tout au début, qui va me servir un peu de 'poubelle à code'. Je vais y tester tous les bouts de mon programme de façon rapide (sans avoir besoin de passer l'interface, et de cliquer manuellement). Et quand livre mon programme, je retire cette procédure 'TestUnitaire()'. (Elle n'est utile que pour moi).

finalement c'est un peu l'idée des tests unitaires, je ne trouve pas ça déconnant, tu as au moins le mérite de le faire, et du coup si pour toi c'est un automatisme de travailler comme ça alors oui intéresse toi aux tests unitaires ...

Bon code,
J@ck.