Как тестировать такие реактовские события кликов в enzyme?

Question

[Игорь Шумиловский]

У меня есть простой компонент кнопки, который по клику бросает flux-экшен.

import React from 'react';
import Button from 'components/Button';

import { loginUser } from 'actions/user';

const LoginButton = () => (
  <Button onClick={() => loginUser('UserName')}>
    Войти
  </Button>
);

export default LoginButton;

Как можно протестировать то, что функция loginUser будет вызвана по клику? Как вообще проверять внешние функции на вызов? Или забить вообще на такие тесты сославшись на тесты самого реакта?

Я использую enzyme, mocha, chai, sinon.

Comments

[copal]

Первостепенной задачей будет тестирование работы самой loginUser, а вот тестировать события реакта вообще не стоит, так они стопудово сработают.

[Игорь Шумиловский]

copal: ага, значит можно не тестить такие события и пропускать так же фабрики экшенов. В этом случае протестить только изменения в сторе?

[copal]

Игорь Шумиловский: я особо с flux не работал, по этому немного сложно отвечать о том чего не знаю, но суть такова что тестировать нужно все где есть хоть какая-то логика логика не написанная Вами.
Я тоже когда-то тестировал создавая приложения на одних тестах, но это настолько сложно, что я забил на это и начал тестировать только логику.

[Максим]

Тестировать, что кнопка кликабельна - по желанию. Здесь как-то мир раскололся =) Сам Дэн [который redux сделал] спрашивал - тестируете ли вы компоненты? (в твиттере)

"пропускать так же фабрики экшенов" - это имеется ввиду не тестировать экшены, а тестировать только reducer (вы это понимаете под "изменения в store?")? Здесь не согласен. Тестировать и экшены и редьюсеры - хорошая идея.

[Игорь Шумиловский]

Максим: если все же тестировать экшены, то я пока вижу только тест на "экшен отправляется" (что еще можно в них протестить?) Тогда как в таком случае проверить, что такой-то такой-то экшен отправляется в диспетчер? Меня просто хоть убей, но грызет желание узнать как тестировать функции в событиях, которые либо подключаются в файле компонента, либо передаются в пропсах. Не подскажете как это сделать? =)

[Игорь Шумиловский]

copal: Вы имеете ввиду "написанная мной" ?

[copal]

Игорь Шумиловский: естественно, зачем Вам тестировать реакт или ещё что-то, что уже протестировано..

[Игорь Шумиловский]

copal: это я уточнил, а то в предыдущем комментарии у Вас наоборот было)

[copal]

Игорь Шумиловский: досадная опечатка!)

[Игорь Шумиловский]

copal: бывает =) Спасибо за ответ)

Answer 1

[Максим]

Игорь, отвечу вам на вопрос - "как в таком случае проверить, что такой-то такой-то экшен отправляется в диспетчер?", который всплыл в комментариях, и на который я изначально был настроен =) Тестировать нужно. Тестируется все по документации

Разберем пример тестирования асинхронного экшен-крейтора на получение списка продуктов:

Для начала код AC (action creator)

export function getProducts() {
  return dispatch => {
    dispatch({ type: PRODUCTS_GET_REQUEST })

    return request.get(`${API_ROOT_V1}/api/v1/products/getAll`)
      .then(res => {
        if (!res.ok) {
          dispatch({ type: PRODUCTS_GET_FAILURE })
          dispatch(showNotification({
            status: 'err',
            text: 'something going wrong',
          }))

        } else {
          dispatch({
            type: PRODUCTS_GET_SUCCESS,
            data: normalize(res.body.data, schema.arrayOfProducts),
          })
        }
      }, err => {
        dispatch({ type: PRODUCTS_GET_FAILURE })
        dispatch(showNotification({
          status: 'err',
          text: err.message,
        }))
      })
  }
}

Получается, для тестирования функции getProducts, которая является AC, мы напишем тест, в котором ожидаем в случае успешного выполнения:
а) что store достигло событие 'PRODUCTS_GET_REQUEST'
б) что store достигло событие 'PRODUCTS_GET_SUCCESS' с некой data (у меня она еще нормализуется, но это не суть)

Для этого, нам потребуется redux-mock-store (взято так же из документации).
Собственно, сам тест:

it('creates PRODUCTS_GET_SUCCESS when get products has been done', () => {

      const data = [
        {
          '_id': '5763e6eccfdb2e9d4baa58ef',
          'name': 'Product A',
          'description': 'Description of A',
          'img': 'no-photo',
          '__v': 0,
          'providers': [],
        },
        {
          '_id': '5763e6eccfdb2e9d4baa58f0',
          'name': 'Product B',
          'description': 'Description of B',
          'img': 'no-photo',
          '__v': 0,
          'providers': [],
        },
      ]

      nock(`${API_ROOT_V1}`)
        .get('/api/v1/products/getAll')
        .reply(200, { data })

      const expectedActions = [
        { type: PRODUCTS_GET_REQUEST },
        { type: PRODUCTS_GET_SUCCESS, data: normalize(data, schema.arrayOfProducts) },
      ]

      const store = mockStore([])

      return store.dispatch(getProducts())
        .then( () => expect(store.getActions()).to.deep.equal(expectedActions) )
    })

То есть, отвечая на вопрос:

как в таком случае проверить, что такой-то такой-то экшен отправляется в диспетчер

1) const store = mockStore([])
2) store.getActions()
3) сравниваем полученное в п.2 с тем, что ожидаем.

Здесь я попутно использовал nock для "мока" запроса к API. И немного подробнее описал ожидаемую "фейковую" дату (хотя это было не обязательно). Главное суть: мы ожидаем, что некоторые "экшены" достигнут стора. Это и протестировали.

Comments

[Игорь Шумиловский]

ого Вы расписали. Спасибо! Редукс я тестировал и у меня не было с ним проблем, а что касается flux архитектуры, то я не могу найти какой-то аналог store.getActions() чтобы сравнить отправляемый экшен с пришедшим