Как тестировать создателей асинхронного действия, которые полагаются на предыдущие вызовы отправки?

Question

У меня есть создатель асинхронного действия, который разбивается на два действия, один из которых сигнализирует о начале действия, а другой - сигнализирует о завершении. Запрос веб в середине асинхронного создателя действий зависит от значений, установленных в первой синхронной отправки:

export function changeFilter(from, to) { 
    return (dispatch, getState, { fetch }) => { 
    // Updates the state with the new values and sets a loading flag 
    dispatch(changeFilterRequest(from, to)); 

    // Now I want to use those newly-set values to build a query 
    // string. However, the stubbed implementation of `dispatch` 
    // doesn't use reducers, so `getState` continues to return the 
    // original value. 
    const { activeUsers } = getState(); 
    return doSomeWebRequest(fetch, activeUsersParams(activeUsers)) 
     .then(response => dispatch(changeFilterSuccess(response))) 
    }; 
} 

implementation of redux-mock-store's dispatch довольно редки, и (очевидно) задним числом, мы никогда не проходят никаких восстановителей к издевались магазин.

Это означает, что первый вызов dispatch не имеет шансов обновить состояние, на которое полагается второй вызов отправки. Затем веб-запрос, который мы делаем, имеет исходные значения для дат to и from, а не обновленных из вызова асинхронного действия.

Я хотел бы избежать непосредственно с помощью from и to значений, передаваемых в changeFilter, как могут быть дальнейшие преобразования, применяемые к параметрам в пределах changeFilterRequest. Опираясь непосредственно на результат getState, я также позволю себе СУХОЙ кучу подобных методов, которые фильтруют по-разному.

Есть ли какие-либо шаблоны, которые я должен соблюдать для этих типов тестов? Есть ли другой способ, которым я должен структурировать своих создателей действия?

Answer 1

Я думаю, что ваш единичный тест должен быть точным и фокусироваться только на объеме функции, которую вы хотите проверить, которая равна changeFilter. Предполагая, что у вас есть еще один модульный тест для changeFilterRequest, который проверяет, как activeUsers рассчитывается и добавляется в магазин, тот факт, что activeUsers создан в магазине в качестве побочного эффекта при рассылке changeFilterRequest, должен быть вне сферы вашего теста, так как changeFilter не должен заботиться как рассчитывается activeUsers. Я думаю, что вы можете смело добавить какое-либо фиктивное значение для activeUsers в ваш издеваемое хранилище, которое не обязательно зависит от значений to и from, которые вы переходите на changeFilterRequest и убедитесь, что ваша функция правильно считывает это значение из магазина и передает его на activeUsersParams ,

Сказанное выше, я настоятельно рекомендовал redux-saga в качестве альтернативы redux-thunk для обработки асинхронных операций только потому, что он упрощает тестирование этих действий без необходимости создавать издевательства или испытывать побочные эффекты, поскольку все ваши действия будут чистыми.