Java, Jhipster & tests unitaires (back end/office)

Ok je verrai ça plus tard alors, là je dois rendre ma doc, et à partir de lundi, support pour les dév'.
Pas impossible, plutôt probable, donc que je te sollicite à nouveau sur 2 ou 3 exemples concrets et sur lesquels je pourrais bloquer.

Parce que, quand je vois le temps que ça m'a pris pour capter (et encore, pas tout compris je pense) et coder cette mini méthode de test... :calim2:
Pas super confiant quoi... :weird::koi:

Donc je pense que j'aurai besoin de toi la semaine prochaine... :ouin::help::arf:

Bon, j'ai présenté ma doc ce matin, et globalement ça va. :king:

2 points cependant:

1.) priorisation des types de classes: controller, service, repository, api, webservices, web, etc...
dans l'absolu, il faut tester TOUTES les classes, donc il faut prioriser et savoir par lesquelles commencer, càd classer les catégories de classes de la plus importante à la moins importante

donc pour toi, quel serait ce classement? :roll:

2.) test-type selon la catégorie de la classe
le CP me soutient qu'il y a des types de tests différents selon que tu sois face à une classe controller, ou service, ou webservice, etc... :weird:

je cite : "dans Jhipster la classe de test n'hérite pas de la même classe mère selon que controller ou service"
(alors même que depuis Junit 4, il n'y a plus d'héritage de TestCase/TestSuite :weird:)

donc je vais encore creuser ça la semaine prochaine... :fem:

mais, on a vu ensemble, que selon toi et ton expérience, rien de spécifique.
donc quid, selon toi? :yaisse3:

un contre argument à lui donner?:koi:

bon WE :lahola:

Hello,

1) le classement doit aller du code le plus complexe au code le moins complexe. Les tests sont là pour valider un comportement, empêcher les régressions, et servir de doc. Si le comportement est trivial, il est moins important de le tester, car les bugs seront plus faciles à trouver. Je mettrais donc le paquet sur le code le plus compliqué.

Quel que soit le projet, je pense que le "coeur" réside dans le code business. Il faudrait donc tester en priorité les services, garants du bon fonctionnement global de l'appli, puis ensuite les dao, garants du dialogue avec un moteur de sgbd donné. Ensuite, à choix. Les "value objets", bien que contenant peu de logique, peuvent être testés très facilement avec la lib dont je t'ai parlé, c'est donc un investissement faible et un gain intéressant, les bugs dans un data objet sont en général difficiles à trouver (personne n'y pense, tellement c'est simple)

2) Pour moi il n'y a pas vraiment de "type" de tests autres que unit vs integration. Mais je ne connais pas JHipster plus que ça donc je ne vais pas trop m'avancer... Moi, tous mes unit test extends simplement Object, avec des annotations. Ensuite en fonction de la lib de test d'intégration utilisée, tu peux effectivement devoir étendre une classe ou l'autre, mais je ne pense pas que ton collègue voulait dire cela. Il voulait sans doute parler de la dualité unit vs intg, et pour moi, test uniatires partout et tests d'intégration sur les controlleurs, qui vont ensuite propager les appels à toutes les couches.

1.) ok ;)

2.) si, pour lui ce n'est pas le débat TU vs TI... mais bien méthodologie de test différente selon qu'on test une classe service, un classe data, controller ou autre... :no:
je vais donc creuser encore ce point en ligne et voir ce que je peux trouver! ;)

Bah c'est bizard, j'ai jamais entendu parler de tests différents selon la couche que l'on test. On fait intervenir des outils différents, par exemple DBUnit pour tester les repository et charger des dataset dans différentes db, mais ça reste du test unitaire standard. On peut mocker certaines parties (bon sur un dao on ne peut pas mocker grand chose...) et faire des assert sur le comportement attendu, mais on ne révolutionne pas la philosophie... Je serais curieux de voir un exemple de ce que ton collègue veut dire.

Peut-être qu'il parle de tests blackbox/whitebox, si c'est le cas ce n'est pas du unit testing, mais du test d'intégration. Voir du test QA/end to end.

Je suis comme toi, je ne sais pas de quoi il parle, mais ce n'est pas force d'avoir essayé... :roll:
J'ai encore qq points à voir/reprendre dans ma doc et je (re)verrai ça encore une fois. :koi:

D'ailleurs si d'autres experts passent sur ce topic, avis à la population!

Selon vous:

- on teste toutes les classes de la même manière, indifféremment de leur type (service, controler, data, etc...)? avez-vous un argumentaire?

OU

- tests spécifiques selon type de classes? avez-vous des exemples?

:roi: :lahola: :roi:

@vos claviers! :king:

Je pense que le mieux ce serait de demander des précisions/exemples à ton collègue...

Il ne sait pas, rien de concret, il lui semble juste avoir cru voir ça dans Jhipster......... :koi:

Bin fais des recherches, et tu verras qu'il n'y a rien qui corresponde...

http://www.jhipster.tech/running-tests/ fait un distingo tests d'intégration, end 2 end, test unitaire, test de charge, mais rien qui ne diffère réellement selon la couche à tester.

Pour moi, soit il vient avec quelque chose de concret, soit il attend que tu finisses ton rapport et tes recommandations... Parce que les mecs qui disent "moi jcrois qu'j'avais lu ça quelque part une fois y'a longtemps mais j'retrouve plus" y'en a plein en info, et faut pas forcément les écouter tout le temps :)

Aaaaah mais tu prêches un convaincu, ce n'est pas moi qu'il faut convaincre!! :mrgreen:
Tu veux son email?? :mouarf:

1.) sur le site de Jhipster, j'ai déjà épluché la rubrique de test, et j'ai fait la même constatation que toi :ave:
après, les TU au niveau Jhipster, c'est que du front end (Karma), donc pas ma problématique, moi je suis back end, mais bon...

2.) j'ai recontacté un vieux pote d'Uni auquel j'ai pensé hier, et idem: :applo:

Citation:

---

Pour les tests U, pour moi tu les testes de la même "manière" effectivement. Tu testes les méthodes (ou l'API) de ta classe peu importe à quel niveau elle se trouve.

---

3.) ton avis je l'avais déjà aussi :ccool:

Donc effectivement, et c'était déjà mon idée au départ, je vais livrer ma doc avec ces préconisations là.
Et s'il revient, je lui demanderai du concret. :pingoin2:

Ok, doc rendue avant le weekend, en l'état comme prévu.
Pas de retour pour le moment. :yaisse:

Et un mois et demi plus tard? Mission terminée?

salut,

oui, oui, depuis +1 mois maintenant... j'avais mis un comm' ici, mais qui n'a visiblement pas été pris... :weird:
-> j'ai présenté ma synthèse le dernier jour, et plus de remarques particulières
-> depuis, je ne sais pas comme je n'y suis plus :koi::mouarf:
-> mais je suppose que j'en aurais entendu parler s'il y avait eu des problèmes, comme ils ont mon email pro ;)

voilà. :)