Я сейчас работаю в компании, которая имеет целую кучу очень специализированных библиотек - библиотек с такими вещами, как внутреннее состояние и адбэк обратного вызова, что делает его практически невозможным для модульного тестирования.
Компания также требует 90% покрытия модульных тестов.Веселье, веселье, веселье.
Одна из вещей, которая делает меня сумасшедшим, это безумие:
Чтобы сделать вызов API, вам нужен токен JWT.Чтобы получить токен JWT, вам необходимо импортировать библиотеку из частного репозитория NPM под названием «jwt-client»
«jwt-client» экспортирует функции «JWTJourney» и «setJWTParams».
setJWTParams принимает объект для типа и области предоставления, который устанавливает внутреннее состояние для использования с JWTJourney.
(То есть у вас есть не только объектно-ориентированный дизайн, но и OO-дизайн, который не структурирован как класс, а независимые функции, изменяющие то, что я должен предположить, является либо глобальной переменной, либо переменной замыкания.)
JWTJourney принимает один параметр - функцию отправки Redux.(Зачем это нужно? Потому что предполагается, что вы используете закрытую библиотеку «dynamic-redux» с уже встроенными редукторами и типами действий - хотя она не позволяет запускать промежуточное ПО, как, скажем, «redux-saga»"or" logger ")
JWTJourney (dispatch) возвращает метод send, который принимает обратный вызов, где первый параметр содержит объект со свойством, называемым token.
Итак, способ, которым это было разработано, был, скажем, вам нужно было сделать вызов API.Вы бы написали такой код.
const data = await JWTJourney(dispatch).send(({token}) => myApiCall(token, params));
Я подумал: у нас асинхронное ожидание, и .send возвращает обещание, так почему бы и нет:
// getToken.js
const getToken = async (dispatch) => await JWTJourney(dispatch).send(({token}) => token)
// logic.js
import getToken from './getToken'
const token = await getToken();
const data = myApiCall(token);
Так что я подумал, что вам не нужновсе время переписывать путешествие JWT и т. д.
Я думал, что это было немного умно.Но что я не знал (и не мог, потому что нет документации), так это то, что код для JWTJourney.send выглядит примерно так:
send: (callback) => {
try {
callback({token: this.token})
catch (err) {
if(err.type === 'OAuthException'){ // if unauthorised
if(!this.token){
this.getNewToken().then(() => callback({token: this.token});
} else {
this.renewToken(this.token).then(() => callback ({token: this.token);
}
}
Другими словами, токен невозобновить, если обратный вызов, переданный в метод отправки не сможет выполнить .
Что означает ... как бы вы справились с такой ситуацией:
const test1 = await JWTJourney(dispatch).send(({token}) => test1Api(token));
const test2 = await JWTJourney(dispatch).send(({token}) => test2Api(token));
expect(test1).not.toEqual(test2);
Если вы имитируете «отправить», вы никак не можете отличить обратный вызов, отправленный в test1, от обратного вызова, отправленного в test2.Это означает, что даже если вы будете насмехаться над .send()
как что-то вроде jest.fn(() => Promise.resolve(mockData))
, вы получите test1 === mockData && test2 === mockData;
Независимо от того, что я делаю, я не могу найти способ для модульного тестирования этого (иОпять же, мне нужно 90% тестового покрытия в соответствии с политикой компании.)
Я ищу две вещи.Во-первых, проверка - я не сумасшедший верно?Это так же, как я думаю, и есть meshugge, верно?
Второе - одно из оправданий такого подхода заключается в том, что, согласно руководству моей команды, вы "никогда не хотите, чтобы токен с истекшим сроком действия висел вокруг магазина Redux".Также вы не можете полагаться на часы, потому что часы конечного пользователя могут быть неправильными.Если вам нужно было что-то переписать с той же функциональностью: токен должен обновиться по истечении срока действия - как бы вы написали это?Потому что у меня странное чувство, что мне придется его переписать.