С подобным кодом у меня всегда было два варианта гарантирования надежной работы:
- Поотлаживать вживую только в своем окружении (хотя окружений всегда куча: [os x browser x platform x version]), записать вызовы моих обработчиков евентов и передаваемые аргументы, сделать моки и повторить на них вызовы от действий вживую
- Использовать тесткафе/сделать свой easytest
С первым вариантом первыми граблями всегда были "цепочка вызовов изменилась" и мои тесты на моках начинают тестировать коня в вакууме. Или другой расклад: я дописал обработчик на новый евент, но не добавил его вызов в цепочку вызовов в старых тестах и старые тесты теперь тестируют коня в вакууме. Или наоборот, отписался от евента и опять мои тесты гарантируют качество коня в вакууме. Вот как сейчас произошло с jquery 3.6: сценарии упавших тестов вживую может быть отлично работают, а сценарии прошедших тестов вживую может быть отлично глючат. Но узнать это можно только вручную проверив все тесты.
Зато эти тесты очень быстро проходят.
Со вторым вариантом огромные расходы, от эмуляции системных событий до своих виртуальных устройств. И разработчиков для такого кода устанешь искать. Все конечно очень надежно, очень дорого и очень долго. Как в test cafe или в easytest. В моих проектах такие средства были всего три раза и те же самые три раза не взлетели. Слишком уж долгий отклик.
UPD 2022.01: Сейчас "долго" стало неактуальным: аппаратные ресурсы стали дешевле, такие тесты можно прогонять в несколько параллельных потоков и получать результат уже через 10-15 минут ( в моем контексте это вполне приемлемое время). Хотя именно с фокусом и сейчас ничего не взлетело.
Поэтому сейчас я пытаюсь делать разумный баланс на моках индивидуально для каждого случая. И по возможности не совмещать с другими областями работу над кодом для сценариев, где будет обработка клавиатурных и мышиных событий (или где будут тачскрины, сенсорные мониторы, новые кнопки мышки, аналоги мышки или несколько устройств сразу).
Комментариев нет:
Отправить комментарий