Discussion :

[dorus-one]

Salut à tous,

Je possède un projet en Vue.js sur lequel je souhaiterais mettre en place des tests unitaires des composants de vue.js.
Mon application marche très bien. Elle est dockerisé et utilise vue-cli pour fournir l’exécution du code en dev (à travers vue-cli-service serve)

Maintenant j'essaie de mettre Webpack en place sur le projet afin de fournir un environnement pour lancé des tests en local comme expliqué par vue.js ici :
Test unitaires vue.js

Lorsque je lance ma commande

Code :

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

npm run test

qui correspond au paramétrage suivant :

Code :

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

mochapack --webpack-config webpack.config.js --require test/setup.js test/**/*.spec.js

Webpack génère des erreurs lors du chargement d'un composant vue qui charge d'autres composants comme ceci :

Code :

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

import AppButton from '../components/Button'

en mentionnant : "Module not found: '../components/Button' in '/Users/xxxx/Sites/xxxx/xxxxx/xxxxxx/src/page'"

Le fichier qui génère ces erreurs est effectivement dans le dossier page. Mais j'ai besoin de charger d'autres composants vue.js qui se trouve ailleurs dans l'arborescence que voici :


projet
---- dist
---- node_modules
---- public
---- src
---- ---- assets
---- ---- components
---- ---- ----- Button.vue
---- ---- mixins
---- ---- page
---- ---- ----- Home.vue
---- main.js
---- test
package.json
webpack.config.js

Ainsi j'essaie d'écrire un test pour le composant Home.vue qui cherche à charger le composant Button.vue qu'il ne trouve pas (uniquement en test car en dev tout fonctionne parfaitement).

Voici mon fichier de configuration webpack :

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
 
const nodeExternals = require('webpack-node-externals')
const VueLoaderPlugin = require('vue-loader/lib/plugin')
const path = require('path')
 
module.exports = {
    externals: [nodeExternals()],
    devtool: 'inline-cheap-module-source-map',
    entry: './main.js',
    context: path.resolve(__dirname+'/src', 'src'),
    resolve: {
        modules: [path.resolve(__dirname, 'src'), 'node_modules']
    },
    module: {
        rules: [
            {test: /\.vue$/, loader: 'vue-loader'},
            {test: /\.scss$/, use: [{loader: 'style-loader'}, {loader: 'css-loader'}, {loader: 'sass-loader'}]}
        ]
    },
    plugins: [
        new VueLoaderPlugin()
    ],
}

Auriez-vous des pistes afin de mieux comprendre pourquoi cela ne fonctionne pas svp ?

Merci pour votre éclairage.

[Marco46]

C'est pas normal d'avoir besoin de webpack pour lancer tes TU. Si t'as besoin de webpack c'est que c'est pas des TU.

[dorus-one]

C'est pas normal d'avoir besoin de webpack pour lancer tes TU. Si t'as besoin de webpack c'est que c'est pas des TU.

Je trouve ta remarque étonnante (je ne critique pas je cherche à comprendre) car j'essaie de mettre en place des TU suivant les indications du site de vuejs que j'ai mentionné plus haut.
Celui-ci se base sur l'outil mochapack qui à un nom très explicite dans le fait d'avoir un outil de test qui utilise webpack pourtant.

D'après toi si je n'ai pas besoin de webpack pour lancer des TU de composants Vue comment puis-je procéder autrement ?

Concernant mon principal problème, je l'ai résolu.

J'ai recupéré la config webpack incluse dans l'outil vue-cli-service qui mentionne utiliser l'alias '@' pour la resolution des modules js.
Au début je ne souhaitais pas utiliser cette technique car je voulais être cohérent entre mon env de dev et de test. Mais comme de base l'outil de vue js l'utilise
alors je l'ai mis dans ma config webpack de test et cela semble fonctionner.
Il s'agissait de la règle suivante :

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
 
    resolve: {
        alias: {
            '@': '/Users/xxxx/xxxx/xxxxx/xxxxx/xxxxxx/src',
            vue$: 'vue/dist/vue.runtime.esm.js'
        },
        extensions: [
            '.mjs',
            '.js',
            '.jsx',
            '.vue',
            '.json',
            '.wasm'
        ],
        modules: [
            'node_modules',
            '/Users/xxxx/xxxx/xxxxx/xxxxx/xxxxxx/node_modules',
            '/Users/xxxx/xxxx/xxxxx/xxxxx/xxxxxx/@vue/cli-service/node_modules'
        ]
    },

Ainsi que ce soit pour mes test ou mon dev je peux déclarer mes imports de code js avec le caractère @ au debut.

Vous me direz maintenant pourquoi je n'utilise pas tout simplement la config du vue-cli-service pour mes tests ?
Lorsque j'essaie je me retrouve avec toute une nouvelle série d'erreurs à gérer. Je procède donc pas à pas mais cela débordera du sujet du topic.

[Marco46]

Webpack sert à générer un livrable. Un test unitaire s'exécute contre une fonction de ton code source, pas du livrable, donc webpack est inutile.

Je te déconseille l'usage des CLI en général quelque soit l'outil (Angular, Vue, React, whatever), ça cache toute la mécanique et ça t'empêche de comprendre soi-disant pour aller plus vite, sauf qu'au premier vrai problème tu perds huit fois le temps économisé initialement.

Il faut mettre les mains dans le cambouis dès le départ, un CLI sert pour faire un POC à l'arrache pas pour dev un vrai projet.

Je te conseille d'utiliser Jest pour tes tests unitaires plutôt que Mocha qui est plutôt un outil utilisé en dev node. Dans le tuto linké je pense que le but de l'usage de webpack est justement de palier à ça mais ça m'a tout l'air d'une belle usine à gaz.

[dorus-one]

Je suis parfaitement d'accord avec toi, que si on peut éviter d'utiliser les CLI intégré il faut éviter. D'ailleurs j'aurais compris ma problématique plus rapidement si effectivement l'application ne passait pas par ce CLI de vue.Js. Malheureusement parfois on ne décide pas de tout donc pour cela pour le moment je dois faire avec.

Concernant ma problématique de test maintenant, j'aimerais bien comprendre ce qui se passe avant de changer de solution éventuelle.
Mais je prend bonne notes de tes conseils et je pense que je testerais JEST effectivement...

Et merci pour tes réponses