Discussion :

[steph68b]

Salut à tous

Une fois de plus, je demande vos avis de pro...

Je viens d'attaquer une mission temporaire dans un contexte techno que je découvre:
-> dev' d'appli web en Java
-> avec Jhipster

Je ne suis pas développeur Java "moderne" (framework & Cie), et tout ceci est 100% nouveau pour moi, mais on me demande de mettre en place les TU.

J'ai déjà pas mal fait de recherches pour appréhender les concepts & différents composants.
Celui qui m'intéresse vraiment est donc KARMA/JASMINE, pour les tests unitaires!

J'ai parcouru la doc, mais elle parle surtout de tests front-end, Angular donc...
Ce qui n'est pas trop ma problématique, car ce qui intéresse la boite en question c'est le back-end, n'ayant pas web pour cette appli (archi complexe avec app tierce).

D'où ma question:
1.) karma peut-il aussi prendre en charge des TU back-end?
2.) où trouver plus d'info là dessus, sachant que tout ce que je trouve ne parle toujours que du front-end?

Bref, tout avis éclairé sera bon à prendre.
Merci les gars.

[Pill_S]

Euh karma et jasmin c'est pour les tests javascript non?

Donc réponse à ta première question: non! c'est purement frontend

Les tests unitaires java, c'est avec JUnit (ou TestNG à la limite), et des api du genre Mockito, AssertJ, Fest, voir Hamcrest...

[steph68b]

Ok c'est donc bien ce que je pensais! Bad luck!

Dans leur environnement (complexe!!) de dév', il y a aussi du SpringBoot et du Gitlab. L'un de ces "produits" embarque t-il un module de TU?
C'est déjà tellement une usine à gaz que greffer encore un autre produit tiers là dedans...

[Pill_S]

JUnit (tout comme AssertJ et Mockito) est une dépendance naturelle de spring-boot. Tu l'as déjà à disposition sans le savoir (à moins qu'il ne soit explicitement exclu dans le pom, mais ça m'étonnerait)

En plus le scope est limité à "test", donc aucun effet de bord possible sur le code de prod. Et personne ne t'en voudra d'utiliser junit sur un projet ^^

PS: on ne dit pas "complexe", on dit "enterprise-grade"

[steph68b]

Ok, vais donc creuser la piste Junit...... et je reviens si besoin.
Merci.

[andry.aime]

Bonjour,

Il y a aussi des frameworks pour les tests d'intégrations/régressions comme Selenium, JWebUnit ...

A+.

[tchize_]

spring framework (et donc springboot) dispose d'une chiée de librairie utilitaire permettant de tester des application spring. Mais ne te leure pas, ça se limite à faciliter le démarrage du frameworks spring dans un environment de test et à tester à plus haut niveau des choses comme spring mvc. L'outil de testing derriere (avec les assert et companie) ce sera junit ou testNg (à choisir) et tout ce qui ne touchera pas au framework spring, ce sera à la mano, comme toujours. Et il y a peu de chance que tu évite Mockito ou un framework de mocking similaire



Si il te demandent d'écrire les unit tests:

soit il y en a déjà et inspire toi d'eux pour ce qui manque histoire de rester en adéquation avec la boite
soit il n'y a rien en place actuellement et vu l'état déjà avancé de l'appli que tu nous décrit avec son usine à gaz & co, t'es parti pour bouffer du unit test inutile pendant des mois.

je dit inutile car un unit test écrit après coup n'a presque aucune utilité. Il confirme juste que l'application fonctionne telle qu'elle a été codée. Alors qu'avec un unit test on veux confirmer normalement qu'elle fonctionne telle qu'elle a été prévue. C'est pour ça que le test devrait être écrit avant l'application.


Pour donne un exemple, c'est comme si un voiture ne roulait pas droit et toi on te demande d'écrire un test après coup. Si tu n'a jamais vu les specs de la voiture, tu va inévitablement écrire un test qui s'assurera dans le futur qu'effectivement la voiture ne roule pas droit et on ne découvrira le problème que le jour où la voiture roulera droit et donc échouera au test .

[steph68b]

J'étais déjà tombé sur la problématique du mocking durant mes recherches, effectivement... terme étrange & barbare derrière lequel se cachait quoi? Mais, au final, concept très simple.

Pour le reste, je ne pense pas que je devrai moi écrire les test, étant donné que:
1.) je ne suis là qu'en bouche-trou (encore 8 semaines), le temps que la vraie ressource embauchée pour ça arrive en poste
2.) je ne connais ni le projet, ni les specs, effectivement
3.) matériellement pas le temps pour être formé

Donc, moi je ne suis là qu'en renfort temporaire, pour les aspects généraux du projet, et aiguiller sur des choix techniques... ou au moins donner des indications et des pistes.
(bref, du superficiel, mais ça rassure le client d'avoir 1 personne de plus, donc voilà...)

D'où mes recherches.

Et effectivement, je suis parti sur Junit.

[steph68b]

à propos de http://www.jhipster.tech/running-tests/
-> test d'intégration & Spring test context
-> kezako?

je viens de donner mes préco sur Junit, et en gros on me dit "oui mais là, on a déjà quelque chose essaye de voir si on ne peut pas utiliser ça, comme c'est déjà du Spring.."
-> en faisant un maven install, les logs listent des tests effectués à la volée

mais bon, moi ça ne me parle pas!

[steph68b]

En gros: test unitaire VS test d'intégration... kézako?

[steph68b]

Ok donc comme dirait l'autre, si j'ai bien tout lu Freud:

• test unitaire (brique n°1): isolation complète des méthodes à tester, avec par conséquent mocking obligatoire
• test d'intégration (brique n°2): test des méthodes en interactions avec le reste de l'appli, et sans mocking donc

et brique 1 + brique 2 formant ensemble l'intégration continue.

J'ai bon?

Du coup, question subsidiaire:
-> comment savoir si Mockito (copain naturel de Spring Boot, donc), ou un autre d'ailleurs, est déjà installé (et quelle version?) dans l'usine à gaz?
(à priori, pas d'exclusion explicite dans le pom.xml - ctrl F sur "mock" ne ramène rien)
-> une ligne de commande, peut être?

[Pill_S]

Tu peux utiliser mvn dependency:tree --> va lister toutes les dépendances et leur scope, donc, tu sauras si la librairie est déjà disponible (spoiler alert: elle l'est). L'autre solution, c'est d'essayer d'importer une classe de la librairie. Si c'est rouge --> pas dans le path. A noter que le classpath dans Eclipse/Intellij peut différer du classpath Maven (Eclipse n'a pas de notion de "scope": toutes les libs sont toujours disponibles. Maven lui, les sépare par scope - JUnit n'est pas disponible hors du scope de test).

Test unitaires: oui, c'est ça. Chaque test ne vérifie que le comportement de la classe / méthode sous sa responsabilité, en faisant abstraction du reste (faire abstraction = mocker pour que le comportement soit prédictible). Plugin maven-surefire, phase test.
Test d'intégration: vérifier que l'ensemble s'imbrique correctement. Ne mock que les choses obligatoires (ex: un webservice qui n'existe pas sur les environnement d'intégration). Plugin maven-failsafe, phase integration-test.

Par contre, la somme des deux n'est pas égale à de l'intégration continue. L'intégration continue consiste à builder l'ensemble à chaque commit, puis à déployer le tout sur un serveur d'intégration. Lancer les tests ne suffit pas à dire que l'on fait de l'IC

[steph68b]

Ok, je vais creuser, merci.

[steph68b]

Bon... les dernières news...

Je pensais que mon rôle s'arrêterait à une simple préco technique, avec éventuellement la création des squelettes des classes de test, à compléter au fur et à mesure par les développeurs.
J'en était arrivé à cette conclusion car j'avais demandé explicitement si on attendait de moi:
1.) juste une orientation technique
OU
2.) de carrément coder ces tests (ce qui me semblait pus que compliqué, ne connaissant ni l'archi ou presque et encore moins le fonctionnel!)?

Réponse: non le codage sera fait par les dév', donc donne-nous une orientation technique.
Super! Ok, j'ai donc potassé à la fois Junit & IntelliJ, voire Mockito aussi, et pondu un joli "howto".

Mais voilà, ce matin on m'explique que ma doc n'est pas mal, mais juste technique et qu'on attend plus de moi, à savoir une véritable stratégie globale de test (quoi? où? comment?), de voir comment tester les micro-services, que j'avais cloné de Git un projet que je pouvais expérimenter, etc...
-> d'ailleurs au passage, on ne teste que les classes de service, pas les autres (data, accès web)??
-> pour moi toute classe doit être testés, sinon à quoi bon??

Or, c'est là que je suis paumé!

Comment faire alors que je:
-> connais pas le produit, ni l'archi, ni spring/soap/rest, ni le fonctionnel, ni tous les outils gravitant autour, que j'ai découvert ici et que je survole à peine depuis 1 mois, etc...
-> ne bite pas grand chose à leur code source d'un tout autre niveau que mes anciens petits dév' natifs... alors que pour le tester il faut déjà le comprendre donc... ce qui pour moi est contraire à ce qui a été dit plus haut ("ce sont les dév' qui vont coder les tests")...
-> n'ai jamais développé avec aucun framework, et que là aussi... actions/services/contrôleurs....

Mission impossible, non??
En fait, je suis tellement paumé, que je ne sais même pas ce que je ne comprend pas, au final...

Alors, question conne dont je connais la réponse, mais, existe-t-il des stratégies génériques/globales de test, sur lesquelles m'appuyer?
Ou juste un début de piste/réflexion pour voir clair dans le brouillard?

Bref, toute aide sera bonne à prendre...
(weekend - 2h... mais hard de ne pas déjà penser à lundi..........)

[Pill_S]

y sont marrants dans ta boîte... enfin marrants pas genre "haha", plutôt marrant genre "elle est où la caméra cachée?"

c'est donc à toi de repenser les pratiques de dév, les stratégies de testing et la mise en place de micro services? toi, le junior? des stratégies globales de tests, ça se décide par la direction informatique en général, et fait intervenir toutes les équipes ainsi que le demandeur et les clients finaux...

question conne: y'a combien de développeurs dans cette structure? il est illusoire de vouloir mettre en place les mêmes pratiques pour 3 dév que dans les grandes entreprises où les départements sont constitués de dizaines de personnes...

Au fait: oui, on test chaque classe individuellement.

sinon alors dans les grandes lignes, du testing, y'en a de tout un tas de type différents...

- le test unitaire
- le test d'intégration
- le test end-to-end automatisé
- le test de charge
- les FAT (Factory Acceptance Test)
- le test manuel
- les UAT (User Acceptance Test)
- etc...

Les tests techniques, effectivement, sont à la charge du développeur (on va dire, les 5 premiers de ma liste). Bien rédigés, il garantissent que le code se conforme bien aux différentes contraintes. Je les ai listé dans l'ordre décroissant de la fréquence d'exécution (dans une journée type, on lance beaucoup plus de tests unitaires que de tests de charge). Niveau outils, on en a déjà parlé, mais on peut un peu détailler:

Test unitaire -> JUnit + Mockito, ça fait le boulot. Pour les parties ultra sensibles, on peut ajouter des tools comme par exemple JAvalanch ou Pytest, qui sont des tools de "mutation testing" (sans détailler, ça permet de tester la pertinence des tests)
Test Intg -> JUnit. On peut ajouter par exemple des outils de BDD (Behavior Driven Development, genre JBehave, JGiven, etc.), ça permet (enfin ça essaie) aux utilisateurs d'écrire eux-même les tests en utilisant une syntaxe proche du français (en pratique ça marche pas, les utilisateurs n'aiment pas avoir à s'investir dans des choses aussi techniques. et au final ça retombe dans les équipes de dév)
Le test end-2-end -> difficile à maintenir mais diablement efficace une fois en place. Avec des outils genre Selenium, JMeter ou d'autres. Permet de simuler des actions utilisateurs et d'effectuer des assertions (eg. quand je me log je suis bien redirigé vers une page qui contient le texte "Bonjour")
Le test FAT -> un membre de l'équipe clic sur tous les boutons de tous les écrans et s'assure que le rendu est correct avec la plateforme définie (eg. Chrome v12)
Les UAT -> le client/demandeur test tout ce qu'il estime nécessaire, tous les cas compliqués, et valide ou non le comportement
...

PS: le testing, c'est un métier.

Les micros services, c'est au niveau des tests d'intégration ou end-2-end que ça va se manifester. Beaucoup plus difficile à mettre en place au vue des nombreuses interactions entre systèmes hétérogènes...

Sinon question: avez-vous des spécifications claires et précises? Parce que qu'avant de demander aux équipes IT d'être parfait, souvent, les demandeurs sont à la ramasse et incapable de formuler clairement leurs besoins...

[steph68b]

Ouais, comme tu dis..........

Alors pour essayer de te répondre:

1.) pas de cam'cach' non, j'aurais préféré, à choisir

2.) 3 dév' + 1 CP + moi, le tout chez le client
(dans ce qui précède: "on" demande blablabla - "on" = CP)

3.) tests unitaires (pour le moment du moins, ensuite on verra les tests d'intégration...)

4.) JUnit + Mockito c'était bien mon choix technique, en effet

5.) testing = métier, je commence à comprendre oui, jamais fait ça avant

6.) c'est le CP qui gère le client, ou son représentant en tout cas

[steph68b]

Bon allez, lundi, alors repartons positivement!
(enfin essayons, du moins!)

Idée (mais va-t-elle vous aller? ):
-> je poste 2 ou 3 petites classes (pas des gros trucs rassurez-vous)
-> et vous me postez leurs classes de tests respectives, avec mock et tout ce qui va bien

Ça me permettra déjà de me faire une idée claire, d'avoir des exemples concrets et surtout 100%fiables, pour m'orienter!
L'idée n'étant pas de VOUS faire faire MON boulot à ma place, évidemment, mais juste d'avoir une base de travaille saine et fiable, venant d'experts.

Parce que chaque outil/concept individuellement, je saisis à peu près, ok.
Par contre, tous ensembles agrégés dans un même projet, là je ne capte plus, trop complexe.

Jouable pour vous?

[Pill_S]

On peut te donner des pistes, mais on ne peut pas vraiment mettre en place tous les aspects du testing...

Faisons comme tu as dit, et on pourra toujours débattre ensuite de ce qu'il pourrait être possible d'intégrer. Mais le sujet est vaste et d'ailleurs des livres entiers ne sont consacrés qu'au testing.... ça sera dur de résumer tout ça dans un forum

[steph68b]

Pas tous les aspects bien sûr, non, on est d'accord.
Vais essayer de trouver des classes représentatives à poster...

Nouvelle réunion ce matin: en gros on me demande, en vrac:
1) mockito permet-il me mocker des webservice? fonctionnement identique pour SOAP & REST (sais même pas ce que c'est!)? et sinon quel framework pour faire ça?
2) de fixer 1 cadre pour les TU selon les cas d'usage: appel à 1 api, microservices, webservices, etc... pour que les dév' sachent quels tests, à minima, ils vont devoir développer
3) monter un projet de test avec tous les exemples

Alors que je ne connais pas l'appli (ni les multiples techno/philosophie qu'elle embarque!), et que tout ça est monstrueusement nébuleux pour moi
Et quand je mets en avant un profil non technique, et des compétences (fonctionnelles, framework, code source, et j'en passe) que je n'ai pas par rapport à eux: "mais si, mais si"

[steph68b]

Bon allez, une toute petite (juste 2 méthodes courtes) qui ne compte pas pour les 2 ou 3 encore à venir, tellement ça doit être peanuts pour toi!
Mais ça me permettra à moi de fixer test+mock sur un exemple basique, mais concret.

classe à tester:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
package xxxxxxxxxxxx.business.service;
 
import xxxxxxxxxxxx.business.repository.CreationCampagneBlocRepository;
import xxxxxxxxxxxx.domain.TDV.CampagneCartouche;
import xxxxxxxxxxxx.domain.alm.Models;
import xxxxxxxxxxxx.domain.alm.copyEntity.Copy;
import xxxxxxxxxxxx.domain.alm.release.Release;
import xxxxxxxxxxxx.domain.alm.release.ReleaseCycle;
import xxxxxxxxxxxx.domain.alm.release.ReleaseFolder;
import xxxxxxxxxxxx.jhutil.config.ApplicationProperties;
import xxxxxxxxxxxx.tool.ObjectRequest;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;
 
import java.util.ArrayList;
 
@Service
public class CreationCampagneBlocService
{
    @Autowired
    RestTemplate restTemplate;
    @Autowired
    ApplicationProperties applicationProperties;
 
    private final CreationCampagneBlocRepository creationCampagneBlocRepository;
 
    public CreationCampagneBlocService (CreationCampagneBlocRepository creationCampagneBlocRepository) {this.creationCampagneBlocRepository = creationCampagneBlocRepository;}
 
    public void templateSearch(CampagneCartouche objectRequest)
    {
        creationCampagneBlocRepository.requestLoging("https://xxxxxxxxxxxxxxx/qcbin/api/authentication/sign-in");
 
        //TODO URLs actuellement en dur !!!! Il faudra récuperer les links en entrées de ce service
 
        String urlEnveloppe = "https://xxxxxxxxxxxxxxx/qcbin/rest/domains/dom_g/projects/greenwich_dev";
 
        String folderReleaseCible = urlEnveloppe+"/"+ Models.RELEASEFOLDER+"s/134";
        int folderTemplateTestLab;
        int folderRoot;
 
        ArrayList<ReleaseFolder> listOfFolderRel= null;
        ReleaseFolder folderRel= null;
 
        ArrayList<Release> listOfReleases= null;
        Release release= null;
 
        ArrayList<ReleaseCycle> listOfCycles= null;
        ReleaseCycle cycle = null;
 
        try {
            creationCampagneBlocRepository.readWithURL(new ObjectRequest().setURLEntity(folderReleaseCible));
        } catch (Exception e) {
            e.printStackTrace();
        }
 
        creationCampagneBlocRepository.requestLoging("https://xxxxxxxxxxxxxxx/qcbin/api/authentication/sign-out");
    }
 
 
    public String copyTemplate(String idSource, String idTarget)
    {
        creationCampagneBlocRepository.requestLoging("https://xxxxxxxxxxxxxxx/qcbin/api/authentication/sign-in");
 
        String response = "";
 
        Copy entityTest = new Copy();
        entityTest.getID().add(idSource);
        entityTest.setTargetParentId(idTarget);
 
        ObjectRequest objectRequest = new ObjectRequest();
        objectRequest.setURLEntity("https://xxxxxxxxxxxxxxx/qcbin/rest/domains/DOM_G/projects/Greenwich_dev/test-set-folders/copy");
        objectRequest.setCopy(entityTest);
 
        try {
            response = creationCampagneBlocRepository.copyEntityWithURL(objectRequest).getBody().toString();
        } catch (Exception e) {
            e.printStackTrace();
        }
 
        creationCampagneBlocRepository.requestLoging("https://xxxxxxxxxxxxxxx/qcbin/api/authentication/sign-out");
 
        return response;
    }
}

la classe de test (Junit4) à compléter (avec mockito 1.9.5, e tuti quanti), stp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public class CreationCampagneBlocServiceTest {
 
    @BeforeClass
    public static void setUpBeforeClass() throws Exception {
    }
 
    @AfterClass
    public static void setUpAfterClass() throws Exception {
    }
 
    @Before
    public void setUp() throws Exception {
    }
 
    @After
    public void tearDown() throws Exception {
    }
 
    @Test
    public void templateSearch() throws Exception {
    }
 
    @Test
    public void copyTemplate() throws Exception {
    }
}