2016-10-22 5 views
3

Итак, допустим, у меня есть следующее действие:испытательный комплекс Асинхронный Redux действия

export function login({ email, password, redirectTo, doNotRedirect }) { 
    return ({ dispatch }) => { 
    const getPromise = async() => { 
     const basicToken = Base64.encode(`${email}:${password}`); 
     const authHeaders = { Authorization: `Basic ${basicToken}` }; 
     const { payload, error } = await dispatch(sendAuthentication(authHeaders)); 

     if (error) throw payload; 

     const { username, token, fromTemporaryPassword } = payload; 
     const encodedToken = Base64.encode(`${username}:${token}`); 

     dispatch(persistence.set('authorizationToken', encodedToken)); 
     dispatch(postGlobalId({ username })); 
     dispatch(setIsLoggedIn(true)); 
     dispatch(setIsFromTemporaryPassword(fromTemporaryPassword)); 

     await dispatch(clientActions.fetchClient); 

     if (doNotRedirect) return; 

     if (fromTemporaryPassword) 
     dispatch(updatePath('/profile/change-password')); 
     else 
     dispatch(updatePath(redirectTo || '/dashboard')); 
    }; 

    return { 
     type: AUTHENTICATION_LOGIN, 
     payload: getPromise() 
    }; 
    }; 
} 

И я хочу, чтобы добавить тесты для него, чтобы повысить надежность кода.

Итак, вот несколько вещей:

  1. Мы отправить заголовки аутентификации и получить данные в ответ
  2. Кидаем ошибку, если какая-то ошибка присутствует в ответе
  3. Мы создали все необходимые лексемы, отправка все необходимые действия, чтобы показать, что мы вошли в систему
  4. Fetching данных клиента
  5. на основе параметров, так и полученных данных, мы перенаправлять необходимого маршрута/не перенаправлять

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

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

Другим решением является просто отделить эту деятельность в нечто вроде следующего:

  • auth
  • setLoginInfo
  • handleRedirects

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

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

+0

Чувство моего чувства заключается в том, что вы должны извлечь большую логику из своего создателя действия thunk и поместить его в отдельные функции утилиты, которые вызывается создателем действия. Каждый из 5 шагов, которые вы указали, должен иметь свои собственные тесты. – therewillbecode

+0

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

+0

Что значит? Все, что я говорю, это то, что у этого создателя действия слишком много логики. Вы должны сделать дополнительные функции, которые будут служить в качестве служебных функций для создателя действия, чтобы улучшить модульность. – therewillbecode

ответ

3

Если у вас есть очень сложные действия, я думаю, что альтернативный (лучше?) Подход состоит в том, чтобы вместо этого выполнять простые синхронные действия (вы даже можете просто отправить полезные нагрузки и, если хотите, сбросить рекламные ролики,), и обрабатывать асинхронную сторону с помощью redux-saga: https://github.com/yelouafi/redux-saga

Redux Saga позволяет очень просто разложить код вашей бизнес-логики на несколько простых функций генератора, которые можно протестировать изолированно. Они также могут быть протестированы без использования основных методов API, вызываемых из-за функции «вызова» в этой библиотеке: http://yelouafi.github.io/redux-saga/docs/api/index.html#callfn-args. Из-за использования генераторов ваш тест может «подавать» значения в сагу, используя стандартный метод iterator.next. Наконец, они значительно облегчают редукторы, чтобы сказать свое мнение, поскольку вы можете проверить что-то из состояния магазина (например, с помощью селектора), чтобы увидеть, что делать дальше в вашей саге.

Если Redux + Redux Saga существовала до того, как я начал использовать свое приложение (около 100 000 JS (X) LOC до сих пор), я бы определенно использовал их.