Как тестировать компонент с локальным стором MobX?

Question

[Павел Диденко]

Есть компонент класс, в его конструкторе инициализируется локальный store MobX вот так:

constructor(props) {
        super(props);
        this.store = new SubscribeStore({
            userId: this.props.userId,
            type: this.props.isFollowers ? 'followers' : 'subscriptions'
        });
    }

В итоге стор лежит в this и при написании тестов не могу найти способ им управлять.
Есть вариант вынести этот стор в глобальное пространство и прокидывать через Provider, но не хотелось бы засорять глобальное пространство. Кто сталкивался с таким?
Для тестов использую Jest и Enzyme

Comments

[Петр Мухуров]

class YourComponent ... {
  render() {
    const { userId, type } = this.props;
  }
}
...
describe("badabum", () => {
  it("parabum", () => {
    const store = new SubscriberStore({});

    const comp = shallow(<YourComponent userId={store.userId} type={store.type} />);
  });
});

[Павел Диденко]

Петр Мухуров, прочитайте внимательно. store лежит в this. А не this.props, т.к. он локальный, а не инжектится через Provider

Импортировать свой класс без стора нельзя

[Петр Мухуров]

Павел Диденко, для какой задачи вам понадобилось инкапсулировать стор? И как вы собираетесь тестировать компонент, изменяя инкапсулированную вещь внутри? Вы сами создали ситуацию, которая требует какого-то кривого решения, код ради кода.

const MyComp = () => {
  const [c, setC] = useState(0);
  const [d, setD] = useState(0);

  return (...)
}

как мне оттестировать c и d? как оттестировать setC/setD?

[Павел Диденко]

Петр Мухуров,

для какой задачи вам понадобилось инкапсулировать стор?

Стор используется всего для 3х компонентов, поэтому использовал локальный стор

И как вы собираетесь тестировать компонент, изменяя инкапсулированную вещь внутри

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

как мне оттестировать c и d? как оттестировать setC/setD?

Использовать setState, как минимум

[Петр Мухуров]

Павел Диденко,

Использовать setState, как минимум

setState как минимум можно использовать у компонент-классов

[Петр Мухуров]

Павел Диденко, если нечем заняться - положите в стейт ссылку на ваш стор, а не в this, и будет вам счастье

[Павел Диденко]

Петр Мухуров, да, точно, тупанул. Ну тогда либо - использовал бы компонент-класс, либо если эта функция висит как обработчик на каком-то элементе - использовал бы simulate

[Петр Мухуров]

Павел Диденко, т. е. из-за того, что не получается оттестировать что-то, что не поддается тестированию в принципе, мы перепишем код так, чтобы это можно было оттестировать (перепишем компонент на класс)?)

[Петр Мухуров]

Павел Диденко, по-дефолту - да, это либо симулирование, если оно участвует в обработчике, либо проверка на длину/контент внутри компонента, при этом доступ к самой переменной нам не нужен - нужен только результат рендеринга

[Павел Диденко]

Петр Мухуров, ну если изначально я понимаю, что мне нужно использовать стейт - я пишу компонент класс. Хуки использую когда мне нужно уже в написанном ФК добавить стейт, поэтому проблемы такого плана практически не возникают

Answer 1

[camelCaseVlad]

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

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

Даже юнит тесты пишите для юзера. Юзеру все равно, вы использовали компонент с мобх или хуки и контекст.

Answer 2

[Павел Диденко]

Пока что сделал такое решение, может кому пригодится. Но мне кажется это костыль.
1) Импортирую свой тестируемый класс
2) Расширяюсь от этого класса новым
3) В конструкторе присваиваю в this.store другой объект с моками
4) в componentDidMount вызываю super.render()

Все это дело рендерю shallow из enzyme, и ShallowRenderer из Jest