8000 Guide: common-tips.md by Yaty · Pull Request #9 · vuejs-fr/vue-test-utils · GitHub
[go: up one dir, main page]

Skip to content

Guide: common-tips.md #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 22 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
common-tips.md: traduction, première itération
  • Loading branch information
Yaty committed Oct 15, 2017
commit 29ba196ad4c226c6f4872c3fc72f86dfa5f7d858
91 changes: 45 additions & 46 deletions docs/en/guides/common-tips.md
10000
Original file line number Diff line number Diff line change
@@ -1,117 +1,116 @@
# Common Tips
# Astuces

## Knowing What to Test
## Savoir quoi tester

For UI components, we don't recommend aiming for complete line-based coverage, because it leads to too much focus on the internal implementation details of the components and could result in brittle tests.
Pour les composants graphiques (UI), nous ne recommandons pas une couverture complète. En effet, cela mène à trop d'attention sur les détails de l'implémentation interne des composants et pourrait produire des tests instables.

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).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vérifient

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interface public (ici public est un adjectif)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(cela peut être un nouveau rendu ou l'envoi d'un évènement)


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).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

un compteur visible de 1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

se fiche de savoir comment le compteur

pas de majuscule à compteur, je rajouterais « de savoir »


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

interface public


This topic is discussed with more details in a [great presentation by Matt O'Connell](http://slides.com/mattoconnell/deck#/).
Ce sujet est discuté plus en détails dans une [très bonne présentation de Matt O'Connell](http://slides.com/mattoconnell/deck#/).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"en détail" -> invariable


## Shallow Rendering
## Rendu superficiel

In unit tests, we typically want to focus on the component being tested as an isolated unit and avoid indirectly asserting the behavior of its child components.
Dans des tests unitaires, on souhaite s'intéresser au composant qui est en train d'être testé comme une unité isolée et ainsi éviter de s'assurer du bon comportement des composants enfants.

In addition, for components that contain many child components, the entire rendered tree can get really big. Repeatedly rendering all child components could slow down our tests.
De plus, pour les composants qui contiennent beaucoup de composants enfant, l'intégralité de l'arbre de rendu peut être énorme. Répétitivement rendre tous les composants pourrait réduire la vitesse de nos tests.

`vue-test-utils` allows you to mount a component without rendering its child components (by stubbing them) with the `shallow` method:
`vue-test-utils` vous permets de monter un composant sans avoir à rendre ses composants enfants (en les ignorants) avec la méthode `shallow` :

```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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

composant sans majuscule, wrapper sans majuscule

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tu n'as pas traduis « Counter » dans le Get Started, tu ne devrais donc pas traduire Component ici

wrapper.vm // l'instace de Vue montée
```

## Asserting Emitted Events
## Affirmer l'émission d'événements
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tu peux mettre

Assertion d'évènements émis

Pour être consistant avec le propos


Each mounted wrapper automatically records all events emitted by the underlying Vue instance. You can retrieve the recorded events using the `wrapper.emitted()` method:
Chaque wrapper monté va automatiquement enregistrer les événements émis par l'instance de Vue en question. Vous pouvez récupérer ces événements en utilisant la méthode `wrapper.emitted()` :
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

évènement (on utilise la graphie rectifié post 1990) (fait un remplacement pour tous les terme événement vers évènement)


``` js
wrapper.vm.$emit('foo')
wrapper.vm.$emit('foo', 123)

/*
wrapper.emitted() returns the following object:
wrapper.emitted() retourne l'objet suivant :
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

`wrapper.emitted()` retourne l'objet suivant :

{
foo: [[], [123]]
}
*/
```

You can then make assertions based on these data:

Vous pouvez ensuite réaliser des assertions sur ces données :
``` js
import { expect } from 'chai'

// assert event has been emitted
// asserte que l'événement est bien émit
expect(wrapper.emitted().foo).toBeTruthy()

// assert event count
// asserte la taille du compteur d'événement
expect(wrapper.emitted().foo.length).toBe(2)

// assert event payload
// asserte le contenu lié à l'événement
expect(wrapper.emitted().foo[1]).toEqual([123])
```

You can also get an Array of the events in their emit order by calling [wrapper.emittedByOrder()](../api/wrapper/emittedByOrder.md).
Vous pouvez aussi récupérer un tableau des événements dans l'ordre d'émition en appelant [wrapper.emittedByOrder()](../api/wrapper/emittedByOrder.md).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

en appelant [`wrapper.emittedByOrder()`](../api/wrapper/emittedByOrder.md)


## Manipulating Component State
## Manipuler l'état d'un composant

You can directly manipulate the state of the component using the `setData` or `setProps` method on the wrapper:
Vous pouvez directement manipuler l'état d'un composant en utilisant la méthode `setData` ou `setProps` sur le wrapper :

```js
wrapper.setData({ count: 10 })
wrapper.setData({ compteur: 10 })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ne pas traduire count (ou alors traduire tout ce qui doit être traduit dans le Get Started)


wrapper.setProps({ foo: 'bar' })
```

## Mocking Props
## Simuler des props

You can pass props to the component using Vue's built-in `propsData` option:
Vous pouvez passer des props au composant en utilisant l'option `propsData` de Vue :

```js
import { mount } from 'vue-test-utils'

mount(Component, {
mount(Composant, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Garder Component si pas de traduction de get-started.md

propsData: {
aProp: 'some value'
aProp: 'une valeur'
}
})
```

You can also update the props of an already-mounted component with the `wrapper.setProps({})` method.
Vous pouvez aussi mettre à jour les props d'un composant déjà monté avec la méthode `wrapper.setProps({})`.

*For a full list of options, please see the [mount options section](../api/options.md) of the docs.*
*Pour une liste complète des options, veuillez regarder [la section sur les options de montage](../api/options.md) de la documentation.*

## Applying Global Plugins and Mixins
## Appliquer des plugins globaux et des mixins

Some of the components may rely on features injected by a global plugin or mixin, for example `vuex` and `vue-router`.
Des composants pourraient se fier à des fonctionnalités injectées par un plugin global ou un mixin, par exemple `vuex` ou `vue-router`.

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 :
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

 [`createLocalVue`](../api/createLocalVue.md)

Tu peux PR l'original chaque fois que tu utilises des ` qu'il n'ont pas mis.


``` js
import createLocalVue from 'vue-test-utils'

// create an extended Vue constructor
// créer un constructeur local de Vue
const localVue = createLocalVue()

// install plugins as normal
localVue.use(MyPlugin)
// installer des plugins comme d'habitude
localVue.use(MonPlugin)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Garder MyPlugin (ou traduire get-started.md)


// pass the localVue to the mount options
mount(Component, {
// passe la localVue aux options de montage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

`localVue`

mount(Composant, {
localVue
})
```

## Mocking Injections
## Simuler des injections

Another strategy for injected properties is simply mocking them. You can do that with the `mocks` option:
Une stratégie alternative pour injecter des propriétés est de simplement les simuler. Vous pouvez faire cela avec l'option `mocks` :

```js
import { mount } from 'vue-test-utils'
Expand All @@ -120,16 +119,16 @@ const $route = {
path: '/',
hash: '',
params: { id: '123' },
query: { q: 'hello' }
query: { q: 'bonjour' }
}

mount(Component, {
mount(Composant, {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Garder Component ou traduire le get-started.md (pensez à counter.js qui deviendra compteur.js)

mocks: {
$route // adds the mocked $route object to the Vue instance before mounting component
$route // ajoute l'objet route simulé à l'instance de Vue avant de monter le composant
}
})
```

## Dealing with Routing
## Gérer le routage

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ou point à point (déjà utilisé pour end-to-end dans une traduction Nuxt).

0