JavaScript

Создание приложения на Vue.js по TDD – обширное руководство для людей, у которых есть время – часть 3

Spread the love

Оригинальная статья: Daniel KuroskiWorking an application in Vue.js with TDD — An extensive guide for people who have time — part 3

Это третья часть в серии статей:

В прошлой статье мы создали простые тесты, связанные с компонентом UserView. Самым интересным был проведенный нами рефакторинг кода, создавший простую базу, которая будет использоваться для тестирования любого компонента в этом проекте.

Теперь давайте углубимся во все тесты компонентов и завершим их, а также интегрируем все это с хранилищем store.

Интеграция хранилища с нашими тестами

Во-первых, давайте изменим наш файл хранилища: src/store/state.js

export default {
  user: {},
}

Давайте создадим файл фикстуры, который будет содержать пример того, как наши реальные данные будут использоваться в наших тестах.

tests/unit/fixtures/user.js

export default {
  "login": "octocat",
  "id": 1,
  "node_id": "MDQ6VXNlcjE=",
  "avatar_url": "https://github.com/images/error/octocat_happy.gif",
  "gravatar_id": "",
  "url": "https://api.github.com/users/octocat",
  "html_url": "https://github.com/octocat",
  "followers_url": "https://api.github.com/users/octocat/followers",
  "following_url": "https://api.github.com/users/octocat/following{/other_user}",
  "gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
  "starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
  "subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
  "organizations_url": "https://api.github.com/users/octocat/orgs",
  "repos_url": "https://api.github.com/users/octocat/repos",
  "events_url": "https://api.github.com/users/octocat/events{/privacy}",
  "received_events_url": "https://api.github.com/users/octocat/received_events",
  "type": "User",
  "site_admin": false,
  "name": "monalisa octocat",
  "company": "GitHub",
  "blog": "https://github.com/blog",
  "location": "San Francisco",
  "email": "octocat@github.com",
  "hireable": false,
  "bio": "There once was...",
  "public_repos": 2,
  "public_gists": 1,
  "followers": 20,
  "following": 0,
  "created_at": "2008-01-14T04:33:35Z",
  "updated_at": "2008-01-14T04:33:35Z"
}

В несем следующие изменения в tests/unit/UserView.spec.js

import { shallowMount, createLocalVue } from '@vue/test-utils'
import Vuex from 'vuex'
import UserView from '@/views/UserView'
import VUserSearchForm from '@/components/VUserSearchForm'
import VUserProfile from '@/components/VUserProfile'
import initialState from '@/store/state'
import userFixture from './fixtures/user'

const localVue = createLocalVue()
localVue.use(Vuex)

describe('UserView', () => {
  let state

  const build = () => {
    const wrapper = shallowMount(UserView, {
      localVue,
      store: new Vuex.Store({ state })
    })

    return {
      wrapper,
      userSearchForm: () => wrapper.find(VUserSearchForm),
      userProfile: () => wrapper.find(VUserProfile)
    }
  }

  beforeEach(() => {
    state = { ...initialState }
  })

  ...
  ...

  it('passes a binded user prop to user profile component', () => {
    // arrange
    state.user = userFixture
    const { userProfile } = build()

    // assert
    expect(userProfile().vm.user).toBe(state.user)
  })
})

Давайте разберемся, что мы здесь сделали.

С помощью shallowMount мы выполняем рендеринг только нашего компонента, без каких-либо сторонних зависимостей и дополнительных настроек.

Ранее наш компонент не знал, как использовать Vuex или какую-либо другую зависимость, которую мы можем использовать в main.js.

Благодаря vue-test-utils у нас есть способ создать локальный экземпляр vue для отправки нашему компоненту. Таким образом, в нашем тесте мы можем указать все зависимости, которые он использует глобально в локальном способе запуске.

  • В строке 9 мы создаем этот локальный экземпляр, делая именно то, что мы обычно делаем в main.js во время запуска Vuex.
  • В строке 13 мы создаем переменную state, которую можно изменять между тестами.
  • В строках 17 и 18 мы отправляем компоненту наш локальный экземпляр vue, как в новое хранилище (опять же, это именно то, что было делается в main.js)
  • В строке 28 мы помещаем beforeEach, как он всегда вызывается между каждым тестом, я пользуюсь возможностью «сбросить» используемые переменные в тестах для получения стандартного значения. В этом случае мы используем исходный файл нашего состояния и сохраняем копию этого файла в нашей переменной состояния между каждым тестом.
  • В строке 37, наконец, мы можем начать видеть одно из преимуществ использования функцию build. Здесь мы гарантируем, что перед запуском этого теста у нас будет переменная состояния state сброшенного к ее первоначальному значению. Затем мы можем изменить его значение с помощью нашей fixture, содержащего «реальные» данные нашего разыскиваемого пользователя, и ТОЛЬКО ТОГДА мы используем build.

Этот способ дает нам большую гибкость, потому что мы можем контролировать наши тесты и вносить изменения перед созданием основного компонента, подлежащего тестированию.

И, наконец, мы можем удалить наш wrapper из теста, поскольку в строке 41 мы хотим гарантировать, что наш компонент отправляет присутствующего пользователя в state, а не в data.

RED

Теперь наш тест не проходит, так как в нашем UserView.vue мы не отправляем через props в VUserProfile.vue пользователя в наше хранилище. Давайте исправим это.

src/views/UserView.vue

<script>
import { mapState } from 'vuex'
import VUserSearchForm from '@/components/VUserSearchForm'
import VUserProfile from '@/components/VUserProfile'
export default {
  name: 'UserView',
  components: {
    VUserSearchForm,
    VUserProfile,
  },
  computed: {
    ...mapState({
      user: 'user',
    })
  }
}
</script>

<template>
  <div>
    <VUserSearchForm />
    <VUserProfile :user="user" />
  </div>
</template>

Теперь мы вставляем mapState, сопоставляем пользовательское свойство нашего магазина и отправляем его в VUserProfile.

GREEN

Супер! Теперь мы гарантируем, что UserView отправляет правильное свойство в VUserProfile.

Последний тест UserView

Мы почти завершили с нашим компонентом. Не хватает только одного функционала.

Я хотел бы гарантировать, что всякий раз, когда VUserSearchForm запускает событие submitted, мы запускаем store action содержащим пользователя, который был набран в нем.

Внесем изменения в tests/unit/UserView.spec.js

jest.mock('@/store/actions')
import { shallowMount, createLocalVue } from '@vue/test-utils'
import Vuex from 'vuex'
import UserView from '@/views/UserView'
import VUserSearchForm from '@/components/VUserSearchForm'
import VUserProfile from '@/components/VUserProfile'
import initialState from '@/store/state'
import actions from '@/store/actions'
import userFixture from './fixtures/user'

const localVue = createLocalVue()
localVue.use(Vuex)

describe('UserView', () => {
  let state

  const build = () => {
    const wrapper = shallowMount(UserView, {
      localVue,
      store: new Vuex.Store({
        state,
        actions,
      })
    })

    return {
      wrapper,
      userSearchForm: () => wrapper.find(VUserSearchForm),
      userProfile: () => wrapper.find(VUserProfile)
    }
  }

  beforeEach(() => {
    jest.resetAllMocks()
    state = { ...initialState }
  })

  ...
  ...

  it('searches for a user when received "submitted"', () => {
    // arrange
    const expectedUser = 'kuroski'
    const { userSearchForm } = build()

    // act
    userSearchForm().vm.$emit('submitted', expectedUser)

    // assert
    expect(actions.SEARCH_USER).toHaveBeenCalled()
    expect(actions.SEARCH_USER.mock.calls[0][1]).toEqual({ username: expectedUser })
  })

})

Давайте сначала разберем наши изменения:

  • Сначала мы создали переменную, содержащую пользователя, который должен быть отправлено через отправленное событие submitted
  • Сразу после этого мы вручную генерируем настраиваемое событие компонента VUserSearchForm, которое и будет происходить в будущем.
  • При этом в строках 50 и 51 мы надеемся, что action хранилища с именем SEARCH_USER было вызвано (запрошено) и что объект, содержащий нашего пользователя, был отправлен в качестве payload.
  • Строка 51 может показаться странной, но это форма, которую мы имеем, чтобы гарантировать, что мы отправляем правильную полезную нагрузку в store actions, потому что мы не вызываем метод из store вручную

То, что мы делаем, это вызываем store.dispatch, а Vuex внутренне вызывает наше действие для нас. И это заканчивается тем, что в первый параметр вводится объект, в который мы получаем свойства из Vuex. И как второй параметр, это наша полезная нагрузка payload.

Затем мы должны вручную принять вызов store, получив второй параметр, который является payload (наше имя пользователя).

Теперь мы можем понять, как проходила подготовка к тесту.

В строке 1 мы используем очень приятный функционал jest. В основном используя jest.mock, jest возьмет файл в том же каталоге, что и наш импортированный файл, и выполнит поиск src/store/__mocks__/actions.js вместо исходного src/store/actions.js.

Это позволяет нам создавать наши mocks, чтобы они могли использоваться всем приложением.

Это также работает для сторонних зависимостей. Мы будет использовать mock вместо всех модулей зависимостей.

Затем в строке 8 мы импортируем actions нашего store, которые на самом деле являются mock файлом, который мы создадим.

Мы вставляем action в store в строке 22.

И, наконец, в строке 34 мы сбрасываем для каждого теста все mock функции в исходное состояние, чтобы ни один тест не влиял на результат других.

RED

Теперь наш тест снова не проходит. Во-первых, нам нужно гарантировать, что мы работаем с mock функцией.

Для этого внесите следующие изменения в src/store/__mocks__/actions.js

import userFixture from '../../../tests/unit/fixtures/user'

export default {
  SEARCH_USER: jest.fn().mockResolvedValue(userFixture)
}

Здесь мы в основном возвращаем объект с нашей функцией SEARCH_USER, возвращаясь к «стандартному» значению, что было бы solved promise для нашего fixture пользователя.

Внесите следующие изменения в src/views/UserView.vue

<script>
import { mapState } from 'vuex'
import VUserSearchForm from '@/components/VUserSearchForm'
import VUserProfile from '@/components/VUserProfile'

export default {
  name: 'UserView',
  components: {
    VUserSearchForm,
    VUserProfile,
  },
  methods: {
    searchUser(username) {
      this.$store.dispatch('SEARCH_USER', { username })
    }
  },
  computed: {
    ...mapState({
      user: 'user',
    })
  }
}
</script>

<template>
  <div>
    <VUserSearchForm
      @submitted="searchUser"
    />
    <VUserProfile :user="user" />
  </div>
</template>

Наконец, в нашем UserView мы можем услышать события, происходящие в VUserSearchForm и при вызове этого мы можем вызвать наши action.

GREEN!

Эти тесты, в основном, охватывают наш компонент UserView. 😄

Для наших следующих компонентов, которые являются только презентационными, мы собираемся немного ускориться, поскольку в основном мы будем тестировать те же самые вещи.

Я собираюсь опубликовать тестовые и производственные файлы полностью, но не буду описывать каждый шаг, чтобы не удлинять эту статью. Но мы будем следовать тем же пошаговым инструкциям, что и прежде.

Тестирование VUserProfile

tests/unit/VUserProfile.spec.js

import { shallowMount } from '@vue/test-utils'
import VUserProfile from '@/components/VUserProfile'
import user from './fixtures/user'

describe('VUserProfile', () => {
  let props

  const build = () => {
    const wrapper = shallowMount(VUserProfile, {
      propsData: props
    })
    return {
      wrapper,
      avatar: () => wrapper.find('.user-profile__avatar'),
      name: () => wrapper.find('.user-profile__name'),
      bio: () => wrapper.find('.user-profile__bio')
    }
  }

  beforeEach(() => {
    props = {
      user
    }
  })

  it('renders the component', () => {
    // arrange
    const { wrapper } = build()
    // assert
    expect(wrapper.html()).toMatchSnapshot()
  })

  it('renders main components', () => {
    // arrange
    const { avatar, name, bio } = build()
    // assert
    expect(avatar().exists()).toBe(true)
    expect(avatar().attributes().src).toBe(props.user.avatar_url)

    expect(name().exists()).toBe(true)
    expect(name().text()).toBe(props.user.name)

    expect(bio().exists()).toBe(true)
    expect(bio().text()).toBe(props.user.bio)
  })
})

Здесь у нас нет ничего нового. Поскольку VUserProfile является компонентом представления.

src/components/VUserProfile.vue

<script>
export default {
  name: 'UserProfile',
  props: {
    user: {
      type: Object,
      required: true,
    }
  }
}
</script>

<template>
  <div class="user-profile">
    <img class="user-profile__avatar" :src="user.avatar_url" />
    <div class="user-profile__name">
      {{ user.name }}
    </div>
    <div class="user-profile__bio">
      {{ user.bio }}
    </div>
  </div>
</template>

Здесь мы добавляем только данные рендеринга, полученные через props.

GREEN

Итак, мы можем идти дальше. 😏

Тестирование VUserSearchForm

tests/unit/VUserSearchForm.spec.js

import { shallowMount } from '@vue/test-utils'
import VUserSearchForm from '@/components/VUserSearchForm'

describe('VUserSearchForm', () => {
  const build = () => {
    const wrapper = shallowMount(VUserSearchForm)

    return {
      wrapper,
      input: () => wrapper.find('input'),
      button: () => wrapper.find('button'),
    }
  }

  it('renders the component', () => {
    // arrange
    const { wrapper } = build()

    // assert
    expect(wrapper.html()).toMatchSnapshot()
  })

  it('renders main child components', () => {
    // arrange
    const { input, button } = build()

    // assert
    expect(input().exists()).toBe(true)
    expect(button().exists()).toBe(true)
  })

  it('calls "submitted" event when submitting form', () => {
    // arrange
    const expectedUser = 'kuroski'
    const { wrapper, button, input } = build()
    input().element.value = expectedUser

    // act
    input().trigger('input')
    button().trigger('click')
    button().trigger('submit')

    // assert
    expect(wrapper.emitted().submitted[0]).toEqual([expectedUser])
  })
})

Опять же, тесты здесь очень похожи.

Здесь мы вставляем вручную в input нашего искомого пользователя и затем запускаем события ввода submitted, указывая, что «мы написали» в input.

И, наконец, нажимаем кнопку submit, чтобы гарантировать, что событие отрабатываем в соответствии с введенным значением.

Таким образом, вы уже изучили основы тестирования компонентов во Vue. Весьма вероятно, что он будет развиваться таким образом и не станет намного сложнее 😅.

src/components/VUserSearchForm.vue

<script>
export default {
  name: 'UserSearchForm',
  data() {
    return {
      username: ''
    }
  }
}
</script>

<template>
  <form @submit.prevent="$emit('submitted', username)">
    <input type="text" v-model="username" />
    <button type="submit">Enviar</button>
  </form>
</template>

Для производственного кода мы только визуализируем форму, а при отправке мы отправляем отправленное событие с именем пользователя.


Тестирование action

Теперь, когда мы рассмотрели все наши тестовые компоненты, мы можем перейти ко второй части, которая будет тестировать наш store, action и mutation.

Есть два способа тестирования store, и я приведу только один из них. Если вы хотите узнать больше, взгляните на книгу Эдда Йербурга Testing Vue.js Applications.

Давайте начнем с тестирования наших action.

tests/unit/actions.spec.js

jest.mock('@/api')
import flushPromises from 'flush-promises'
import actions from '@/store/actions'
import api from '@/api'
import userFixture from './fixtures/user'

describe('store actions', () => {
  let commit

  beforeEach(() => {
    commit = jest.fn()
  })

  it('searches for user', async () => {
    // arrange
    const expectedUser = 'kuroski'
    
    // act
    await actions.SEARCH_USER({ commit }, { username: expectedUser })
    await flushPromises()
    
    // assert
    expect(api.searchUser).toHaveBeenCalledWith(expectedUser)
    expect(commit).toHaveBeenCalledWith('SET_USER', userFixture)
  })
})

В этом случае у нас есть только одно действие. Затем мы выполняем ручной вызов метода SEARCH_USER с поддельным коммитом, отправляющим username.

В строке 20 мы используем зависимость, которую мы скачали в начале проекта. Это гарантирует, что все promises были выполнены на данный момент.

Наконец, при вызове действия мы надеемся, что наша служба API была вызвана в функции searchUser и что наш пользователь был отправлен.

Кроме того, поскольку мы тестируем только успешный путь, по которому запрос будет успешно выполнен, мы надеемся, что наш коммит был вызван с нашей fixture, где он представляет собой макет ответа API Github.

src/__mocks__/api.js

import userFixture from '../../tests/unit/fixtures/user'

export default {
  searchUser: jest.fn().mockResolvedValue(userFixture)
}

src/api.js

export default {}

Поскольку мы используем jest.mock (‘@/api.js’), нам нужно создать наш mock файл. Позже мы собираемся создать нашу службу запросов, но сейчас для наших тестов мы можем использовать наш производственный файл только как export default.

Чтобы не делать нашу статью еще длиннее, я собираюсь только проверить успешный путь. Мы не будем здесь рассматривать альтернативные варианты, например, сбой запроса, ошибка сети и т. д.

Ну … мы только что достигли красного этапа:

RED

По сути, наш метод все еще не существует. Наконец-то мы можем реализовать наш SEARCH_USER.

src/store/actions.js

import api from '@/api'

export default {
  SEARCH_USER({ commit }, { username }) {
    return new Promise(async (resolve, reject) => {
      try {
        const user = await api.searchUser(username)
        commit('SET_USER', user)
        resolve(user)
      } catch(error) {
        reject(error)
      }
    })
  }
}

Мы можем сделать производственный код разными способами. В этом случае я решил вернуть promise.

И здесь мы делаем все, что мы требуем в нашем тесте. Во-первых, я вызываю наш api.searchUser, отправляя имя пользователя, которое используется в качестве параметра.

Сразу после получения ответа я совершаю мутацию, отправляю нашего пользователя и возвращаю службу API.

GREEN

Отлично! Теперь все тесты проходят.

Тестирование mutation

Мутация должна быть самым простым случаем, с которыми мы имели дело до сих пор.

tests/unit/mutations.spec.js

import mutations from '@/store/mutations'
import initialState from '@/store/state'
import user from './fixtures/user'

describe('mutations', () => {
  let state

  beforeEach(() => {
    state = { ...initialState }
  })

  it('sets new user', () => {
    // arrange
    const expectedUser = user

    // act
    mutations.SET_USER(state, expectedUser)

    // assert
    expect(state.user).toEqual(expectedUser)
    expect(state.user).not.toBe(expectedUser)
  })
})

Здесь все просто. Перед каждым тестом мы сбрасываем наше локальное «состояние», и то, что мы делаем, напрямую вызываем нашу мутацию, отправляя это состояние, передавая нашего пользователя.

В конце концов, мы надеемся, что в state было передано нашего пользователя, и здесь я хочу убедиться, что это чистая функция. Итак, я хочу гарантировать, что значение состояния state является копией исходного пользователя.

RED

Теперь, когда наш тест не проходит, давайте перейдем к реализации мутации.

src/store/mutations.js

export default {
  SET_USER(state, user) {
    state.user = { ...user }
  }
}

Выполнено! Я знаю, что в случае с Vue.js мне не нужно беспокоиться о том, чтобы сделать копию объекта, из-за того, как он работает с реактивностью, но лично я хотел бы сохранить свои мутации как чистые функции. Что бы не было бы никаких проблем, если вы вдргу сделаете что-то вроде: state.user = user.

Просто не забудьте изменить тест, если вам потребуется сделать это таким образом.

GREEN

Наш тест прошел 😄


Заключение

В этой третьей статье мы сделали:

  • Завершили тестирование всех компонентов
  • Создали интегрированные тесты со store

Далее мы завершим наш компонент с интеграцией с хранилищем.

Следующая часть
Твиттер автора оригинальной статьи : @DKuroski

Была ли вам полезна эта статья?
[2 / 3]

Spread the love
Editorial Team

Recent Posts

Vue 3.4 Новая механика v-model компонента

Краткий перевод: https://vuejs.org/guide/components/v-model.html Основное использование​ v-model используется для реализации двусторонней привязки в компоненте. Начиная с Vue…

11 месяцев ago

Анонс Vue 3.4

Сегодня мы рады объявить о выпуске Vue 3.4 «🏀 Slam Dunk»! Этот выпуск включает в…

11 месяцев ago

Как принудительно пере-отобразить (re-render) компонент Vue

Vue.js — это универсальный и адаптируемый фреймворк. Благодаря своей отличительной архитектуре и системе реактивности Vue…

2 года ago

Проблемы с установкой сертификата на nginix

Недавно, у меня истек сертификат и пришлось заказывать новый и затем устанавливать на хостинг с…

2 года ago

Введение в JavaScript Temporal API

Каким бы ни было ваше мнение о JavaScript, но всем известно, что работа с датами…

2 года ago

Когда и как выбирать между медиа запросами и контейнерными запросами

Все, кто следит за последними событиями в мире адаптивного дизайна, согласятся, что введение контейнерных запросов…

2 года ago