Итак, допустим, у меня есть следующее действие:испытательный комплекс Асинхронный 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()
};
};
}
И я хочу, чтобы добавить тесты для него, чтобы повысить надежность кода.
Итак, вот несколько вещей:
- Мы отправить заголовки аутентификации и получить данные в ответ
- Кидаем ошибку, если какая-то ошибка присутствует в ответе
- Мы создали все необходимые лексемы, отправка все необходимые действия, чтобы показать, что мы вошли в систему
- Fetching данных клиента
- на основе параметров, так и полученных данных, мы перенаправлять необходимого маршрута/не перенаправлять
Вопрос в том, что это действительно слишком сложно проверить, и нам нужно буквально заглушить все, что плохо из-за хрупких тестов, хрупкости и слишком большой реализации знаний (не говоря уже о том, что это довольно сложно диспетчер шлейфа для правильной работы).
Таким образом, следует ли тестировать все эти 5 баллов или сосредоточиться только на наиболее важных вещах, таких как отправка запроса авторизации, сброс ошибки и проверка перенаправления? Я имею в виду проблему со всеми флагами, которую они могут изменить, поэтому она не настолько надежна.
Другим решением является просто отделить эту деятельность в нечто вроде следующего:
auth
setLoginInfo
handleRedirects
И пройти все необходимые функции для вызова через инъекции зависимостей (вот только с параметрами, в основном)? При таком подходе я могу шпионить только за вызовами этих функций, не вдаваясь в подробности.
Я вполне доволен модульным тестированием чистых функций и обработкой различных кромки для них (без тестирования слишком большой реализации, только результата), но для меня сложнее проверить сложные функции с побочными эффектами.
Чувство моего чувства заключается в том, что вы должны извлечь большую логику из своего создателя действия thunk и поместить его в отдельные функции утилиты, которые вызывается создателем действия. Каждый из 5 шагов, которые вы указали, должен иметь свои собственные тесты. – therewillbecode
Но это не функция полезности, это точно бизнес-логика. Да, я могу сделать их чистыми - но мне в основном нужно проверить, что они вызваны, иначе слишком много деталей реализации. – Bloomca
Что значит? Все, что я говорю, это то, что у этого создателя действия слишком много логики. Вы должны сделать дополнительные функции, которые будут служить в качестве служебных функций для создателя действия, чтобы улучшить модульность. – therewillbecode