Guide: common-tips.md #9
Conversation
…', 'getting-started.md', 'testing-SFCs-with-jest.md', 'testing-SFCs-with-mocha-webpack.md', 'using-with-vue-router.md' and 'using-with-vuex.md' of https://github.com/Yaty/vue-test-utils into common-tips.md
There was a problem hiding this comment.
Globalement je vois que tu as pris le parti de tout traduire (même les nom de variable) dans cette traduction alors que tu ne l'avais pas fait pour le fichier get-started.md
Personnellement je préfère ne traduire que les valeurs de variable et commentaire et pas les noms de variables mais ceci est uniquement basé sur mon opinion. Je ne vois donc pas d'objection à ce que les noms de variables et fonction soit aussi en français pour aider le lecteur.
Il faut juste que tu fasses un choix et que tu t'y tienne à travers toute la traduction !
Pour infos voici ce qui as déjà été fait :
- vuejs.org guide (juste contenu et commentaire en français)
- vuejs.org API (tout traduit)
- vuex (juste contenu et commentaire en français)
- vue-router (juste contenu et commentaire en français)
- vue-ssr-docs (juste contenu et commentaire en français)
- nuxt (juste contenu et commentaire en français)
Toi qui voit !
docs/en/guides/common-tips.md
Outdated
|
|
||
| For example, for the `Counter` component which increments a display counter by 1 each time a button is clicked, its test case would simulate the click and assert that the rendered output has increased by 1. The test doesn't care about how the Counter increments the value, it only cares about the input and the output. | ||
| Par exemple, pour le composant `Compteur`, qui incrémente un compteur visible par un à chaque fois qu'un bouton est cliqué, le scénario de test devrait simuler le clic puis s'assurer que le rendu visuel a bien été incrémenté d'un aussi. Le test se fiche de comment le Compteur a incrémenté la valeur, il s'occupe seulement de l'entrée et de la sortie (le résultat). |
There was a problem hiding this comment.
Par exemple, pour le composant `Counter`
Pour rester consistant avec get-started.md qui traduit uniquement les valeur de chaine de caractère et les commentaires (pas les nom de fichier, pas les nom de fonction, pas les objets, etc.)
(du résultat)
pour rester cohérant avec de l'entrée et de la sortie
There was a problem hiding this comment.
se fiche de savoir comment le compteur
pas de majuscule à compteur, je rajouterais « de savoir »
docs/en/guides/common-tips.md
Outdated
|
|
||
| Instead, we recommend writing tests that assert your component's public interface, and treat its internals as a black box. A single test case would assert that some input (user interaction or change of props) provided to the component results in the expected output (render result or emitted custom events). | ||
| A contrario, nous recommandons d'écrire des tests qui vérifie le bon fonctionnement de l'interface publique de vos composants et ainsi traiter le cœur de ceux-ci telle une boîte noire. Un simple test pourrait vérifier qu'une entrée utilisateur (dû à une interaction ou un changement de props) passée au composant nous donnerait le résultat attendu (cela peut être visuel ou l'envoi d'un événement). |
There was a problem hiding this comment.
interface public (ici public est un adjectif)
There was a problem hiding this comment.
dûe (car il me semble que « dû » fait référence à l'entrée utilisateur passée au composant et non pas au test)
docs/en/guides/common-tips.md
Outdated
|
|
||
| Instead, we recommend writing tests that assert your component's public interface, and treat its internals as a black box. A single test case would assert that some input (user interaction or change of props) provided to the component results in the expected output (render result or emitted custom events). | ||
| A contrario, nous recommandons d'écrire des tests qui vérifie le bon fonctionnement de l'interface publique de vos composants et ainsi traiter le cœur de ceux-ci telle une boîte noire. Un simple test pourrait vérifier qu'une entrée utilisateur (dû à une interaction ou un changement de props) passée au composant nous donnerait le résultat attendu (cela peut être visuel ou l'envoi d'un événement). |
There was a problem hiding this comment.
(cela peut être un nouveau rendu ou l'envoi d'un évènement)
docs/en/guides/common-tips.md
Outdated
|
|
||
| The benefit of this approach is that as long as your component's public interface remains the same, your tests will pass no matter how the component's internal implementation changes over time. | ||
| Le bénéfice de cette approche est que tant que l'interface publique de votre composant reste la même, vos tests passeront et ce peu importe le comportement interne de votre composant, qui pourrait changer avec le temps. |
docs/en/guides/common-tips.md
Outdated
|
|
||
| ```js | ||
| import { shallow } from 'vue-test-utils' | ||
|
|
||
| const wrapper = shallow(Component) // returns a Wrapper containing a mounted Component instance | ||
| wrapper.vm // the mounted Vue instance | ||
| const wrapper = shallow(Composant) // retourne un Wrapper contenant une instance de Composant montée |
There was a problem hiding this comment.
composant sans majuscule, wrapper sans majuscule
There was a problem hiding this comment.
Tu n'as pas traduis « Counter » dans le Get Started, tu ne devrais donc pas traduire
Componentici
docs/en/guides/common-tips.md
Outdated
|
|
||
| If you are writing tests for components in a specific app, you can setup the same global plugins and mixins once in the entry of your tests. But in some cases, for example testing a generic component suite that may get shared across different apps, it's better to test your components in a more isolated setup, without polluting the global `Vue` constructor. We can use the [createLocalVue](../api/createLocalVue.md) method to achieve that: | ||
| Si vous écrivez des tests pour des composants dans une application spécifique, vous pouvez mettre en place les mêmes plugins globaux et mixins en une seule fois dans vos tests. Dans certains cas, comme tester un composant générique utilisé par des applications différentes, il est favorable de tester ces composants dans une installation plus isolée, sans avoir à polluer le constructeur global `Vue`. On peut utiliser la méthode [createLocalVue](../api/createLocalVue.md) pour faire cela : |
There was a problem hiding this comment.
[`createLocalVue`](../api/createLocalVue.md)
Tu peux PR l'original chaque fois que tu utilises des ` qu'il n'ont pas mis.
docs/en/guides/common-tips.md
Outdated
| // install plugins as normal | ||
| localVue.use(MyPlugin) | ||
| // installer des plugins comme d'habitude | ||
| localVue.use(MonPlugin) |
There was a problem hiding this comment.
Garder MyPlugin (ou traduire get-started.md)
docs/en/guides/common-tips.md
Outdated
|
|
||
| // pass the localVue to the mount options | ||
| mount(Component, { | ||
| // passe la localVue aux options de montage |
docs/en/guides/common-tips.md
Outdated
| } | ||
|
|
||
| mount(Component, { | ||
| mount(Composant, { |
There was a problem hiding this comment.
Garder Component ou traduire le get-started.md (pensez à counter.js qui deviendra compteur.js)
docs/en/guides/common-tips.md
Outdated
|
|
||
| Since routing by definition has to do with the overall structure of the application and involves multiple components, it is best tested via integration or end-to-end tests. For individual components that rely on `vue-router` features, you can mock them using the techniques mentioned above. | ||
| Depuis que le routage, par définition, porte sur la structure générale de l'application et implique plusieurs composants. Il est mieux testé via des tests d'intégration ou end-to-end. Pour des composants individuels qui se fie aux fonctionnalités de `vue-router`, vous pouvez les simuler en utilisant les techniques mentionnées plus haut. |
There was a problem hiding this comment.
ou point à point (déjà utilisé pour end-to-end dans une traduction Nuxt).
|
Ok merci pour la review, du coup je pars sur traduire uniquement le contenu et les commentaires histoire d'uniformiser ça. |
|
Ok, je m'occupe que du fichier common-tip |
docs/en/guides/common-tips.md
Outdated
|
|
||
| Since routing by definition has to do with the overall structure of the application and involves multiple components, it is best tested via integration or end-to-end tests. For individual components that rely on `vue-router` features, you can mock them using the techniques mentioned above. | ||
| Depuis que le routage, par définition, porte sur la structure générale de l'application et implique plusieurs composants. Il est mieux testé via des tests d'intégration ou point à point (end-to-end). Pour des composants individuels qui se fie aux fonctionnalités de `vue-router`, vous pouvez les simuler en utilisant les techniques mentionnées plus haut. |
There was a problem hiding this comment.
« end-to-end » pour rester consistant avec les autres docs.
Et je t'ai dit des conneries, c'est de « bout en bout » : https://fr.nuxtjs.org/guide/development-tools/
Vraiment désolé :(
|
Je continue en partant du postulat commentaire et valeur :) |
|
|
||
| A test runner is a program that runs tests. | ||
| Un lanceur de tests est un programme qui lance des tests (et oui !). |
There was a problem hiding this comment.
On écrit "eh oui !". C'est une interjection :)
|
|
||
| There are a few things to consider when choosing a test runner though: feature set, performance, and support for single-file component (SFC) pre-compilation. After carefully comparing existing libraries, here are two test runners that we recommend: | ||
| Il y a tout de même plusieurs choses à considérer afin de choisir un lanceur de tests : variété des fonctionnalités, performance et support de la pré-compilation des composants monofichiers (SFC). Après avoir cautionnement analysé et comparé les bibliothèques, il y a deux lanceurs de tests que nous recommandons : |
|
|
||
| - [Jest](https://facebook.github.io/jest/docs/en/getting-started.html#content) is the most fully featured test runner. It requires the least configuration, sets up JSDOM by default, provides built-in assertions, and has a great command line user experience. However, you will need a preprocessor to be able to import SFC components in your tests. We have created the `jest-vue` preprocessor which can handle most common SFC features, but it currently does not have 100% feature parity with `vue-loader`. | ||
| - [Jest](https://facebook.github.io/jest/docs/en/getting-started.html#content) est le lanceur de test le plus complet en terme de fonctionnalités. Il requiert une configuration minimale, installe JSDOM par défaut, fournit des assertions prêtes à l'usage et a une très bonne interface en ligne de commandes. Cependant, vous allez avoir besoin d'un pré-processeur afin d'être capable d'importer les composants monofichiers dans nos tests. On a créé le préprocesseur `jest-vue` qui peut gérer les fonctionnalités communes des composants monofichiers. Il n'y a cependant pas encore autant de fonctionnalités que vue-loader. |
|
|
||
| `vue-test-utils` relies on a browser environment. Technically you can run it in a real browser, but it's not recommended due to the complexity of launching real browsers on different platforms. Instead, we recommend running the tests in Node.js with a virtual browser environment using [JSDOM](https://github.com/tmpvar/jsdom). | ||
| `vue-test-utils` se fie à un environnement de navigateur. Techniquement, vous pouvez le lancer dans un vrai navigateur, mais cela n'est pas recommandé dû à la complexité de lancer de réels navigateur sur différentes plateformes. Au lieu de cela, nous recommandons de lancer les tests sous Node.js avec un environnement virtuel de navigateur en utilisant le [JSDOM](https://github.com/tmpvar/jsdom). |
docs/en/guides/common-tips.md
Outdated
|
|
||
| Instead, we recommend writing tests that assert your component's public interface, and treat its internals as a black box. A single test case would assert that some input (user interaction or change of props) provided to the component results in the expected output (render result or emitted custom events). | ||
| A contrario, nous recommandons d'écrire des tests qui vérifient le bon fonctionnement de l'interface public de vos composants et ainsi traiter le cœur de ceux-ci telle une boîte noire. Un simple test pourrait vérifier qu'une entrée utilisateur (due à une interaction ou un changement de props) passée au composant nous donnerait le résultat attendu (cela peut être un nouveau rendu ou l'envoi d'un évènement). |
|
|
||
| The actions are [jest mock functions](https://facebook.github.io/jest/docs/en/mock-functions.html). These mock functions give us methods to assert whether the actions were called or not. | ||
| Les actions sont des [fonctions de simulations de Jest](https://facebook.github.io/jest/docs/en/mock-functions.html). Ces fonctions nous donnent accès à des méthodes afin de réaliser des assertions si l'action à été appelée ou non. |
|
|
||
| Now the way we define the store might look a bit foreign to you. | ||
| La manière dont on définit le store peut vous paraître un peu étrange. |
|
|
||
| The most important thing to note in this test is that **we create a mock Vuex store and then pass it to vue-test-utils**. | ||
| La chose la plus importante à noter dans ce test est que **l'on créer une simulation d'un store Vuex, qui est ensuite passer à vue-test-utils**. |
| const wrapper = shallow(Actions, { store, localVue }) | ||
| const p = wrapper.findAll('p').at(1) | ||
| expect(p.text()).toBe(getters.clicks().toString()) | ||
| }) | ||
| }) | ||
| ``` | ||
| This test is similar to our actions test. We create a mock store before each test, pass it as an option when we call `shallow`, and assert that the value returned by our mock getters is being rendered. | ||
| Ce test est similaire à notre test sur les actions. On créer un store fictif avant chaque test, on le passe ensuite comme une option lorsque l'on appele `shallow`. Pour finir, on asserte que la valeur retournée par nos getters fictifs est bien affichée. |
|
|
||
| This is great, but what if we want to check our getters are returning the correct part of our state? | ||
| C'est génial, mais comment faisons nous pour vérifier que nos getters retournent correctement les parties du state ? |
|
Je corrige ça dans la soirée. Je répète j'ai foiré la PR, celle-ci ne concerne que common-tips.md. Je prends quand même tes corrections qui vont être faites sur les PR correspondantes :) |
@Yaty Ah oui excuse-moi, j'ai raté ce commentaire :) Du coup tu as quand même mes suggestions pour les autres PR (je repasse volontiers sur les autres quand elles sont là)! |
|
@rspt ok les PR sont corrigées ! |
|
On te laisse résoudre le conflit @Yaty pour passer ta PR ou en soumettre une autre avec seulement le bon fichier corrigé proposé ;) |
Voir #18