Метаморфоза тестирования redux-saga

[faiwer]

Подскажите, а вот тут:

код из статьи

it('should change click counter (integration test)', async () => {
    const initialState = {
        clickCount: 11,
    }            

    const saga = expectSaga(mainSaga)
        .provide([
            call(ServerApi.SendClick), 14],
            call(ServerApi.SendUnclick), 18]
        ])
        .withReducer(rootReducer, initialState)

    const result = await saga
        .dispatch(Actions.click())
        .dispatch(Actions.unclick())
        .run()

    expect(result.storeState.clickCount).toBe(18)
})

мы не можем проверить промежуточный результат (14) тоже? А то получается что это по сути тест на unclick.

[ypastushenko]

Хорошее замечание. Я сам об этом думал, когда делал пример. Он, действительно, получился не очень удачным, но проверять промежуточный результат я бы не стал, т.к. в этом случае нарушится требование сфокусированности теста — у теста появится вторая причина для падения.
Здесь два dispatch подряд можно интерпретировать как то, что мы хотим проверить, что событие click() никак не изменит то, что в итоге в стейт будет просуното то, что вернётся в последнем событии.

[faiwer]

сфокусированности теста — у теста появится вторая причина для падения

Разве это не прекрасно? Это же ведь интеграционный тест.

[ypastushenko]

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

[Druu]

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

Сфокусированность теста обратно пропорциональна его полезности. Т.е., набор несфокусированных тестов всегда строго лучше, чем эквивалентный набор сфокусированных, т.к. отловит строго большее количество ошибок.

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

[ypastushenko]

Сфокусированность теста обратно пропорциональна его полезности. Т.е., набор несфокусированных тестов всегда строго лучше, чем эквивалентный набор сфокусированных, т.к. отловит строго большее количество ошибок.

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

Я привык считать полезностью теста то, насколько он облегчает разработку. По опыту, тест, который падает на каждый чих не очень полезен, т.к. при его падении непонятно что конкретно сломалось.

[Druu]

Я привык считать полезностью теста то, насколько он облегчает разработку.

Это очень расплывчатое определение, а потому бессодержательное. Можно много вещей придумать, которые упрощают разработку, следует ли из этого, что все эти вещи — хорошие тесты? Т.е. хороший тест — он упрощает разработку вполне определенным образом. Каким? Дешевое обнаружение ошибок.

По опыту, тест, который падает на каждый чих не очень полезен, т.к. при его падении непонятно что конкретно сломалось.

Здесь важно разделять два фактора, по причине которых могут падать тесты. Во-первых, хрупкость (когда тест падает из-за рефакторинга, а не из-за реальной ошибки), и, во-вторых, с-но корректное срабатывание, когда тест находит реальную ошибку. Вот во втором случае, лучше пусть тест падает на 10 реальных ошибках, и при этом не показывает, в чем конкретно эти ошибки, чем падает только на одной, а 9 уходят дальше. Ресурсов на поиск и отладку этих 9 ошибок в итоге уйдет почти наверняка сильно больше чем на уточнение их в рамках "несфокусированного" теста.
В случае же с хрупкостью — это отдельный вопрос, тут уже речь не о сфокусированности, а о том, чтобы не было привязки к реализации (ваш тест, например, очень хрупкий, т.к. привязан к реализации — в нем упоминаются clickSuccess и sendClick; в идеале в тесте не должно упоминаться никаких используемых в тестируемой ф-и зависимостей).

[faiwer]

По опыту, тест, который падает на каждый чих не очень полезен, т.к. при его падении непонятно что конкретно сломалось.

Возможно у вас идеальные условия для работы. Мне пока в таких конторах работать не доводилось. Наоборот, время на написание тестов исчезающе мало, и если тест может упасть — пусть падает, даже если он падает на каждый чих (при условии что чих требует починки). Ведь если никто не упадёт на этот чих, то его выявление и починка потребует куда большего времени. В разы большего.

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