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

Тестирование важно. Это делает каждый программист. Тестирование вашего кода с различными входами - это тестирование, с которым каждый из нас знаком.

Написание автоматических тестов - пустая трата времени в 99% случаев.

Да, автоматические тесты имеют следующие преимущества по сравнению с «ручным тестированием»:

  • Вы пишете тест один раз и можете запустить его миллион раз. Если ваш код изменится из-за проверки кода или рефакторинга, вы можете просто запустить его повторно.
  • Он может служить записью для проверки кода, что вы продумали во всех крайних случаях.
  • При создании новой функции они служат доказательством того, что вы не сломали остальную систему.

Тесты требуют значительных затрат, поскольку программисты TDD тратят на написание тестов почти половину своего времени.

Это может быть приемлемо, если мы запустим тест сотни раз. Однако TDD рекомендует писать в основном модульные тесты.

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

Неудачные тесты полезны только в случае неожиданного сбоя.

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

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

Можем ли мы сделать лучше?

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

Можем ли мы сделать написание тестов таким же простым, как тестирование вручную?

Прямо сейчас на тестовом поле происходят крутые вещи. Все началось с clojure.spec, который может генерировать ваши тесты из простых инвариантов, которые вы указываете для своего кода. Это следующее, что мы изучим с Clojure, и вам стоит его проверить.

А еще есть новые классные снимки Jest! Представьте, что вы можете записать свое ручное тестирование, а затем просто передать его в репозиторий. Что ж, это почти то же самое с Jest Snapshots.

В чем их самое большое преимущество? Больше никаких мучительных переписываний тестов. Вы просто воссоздаете снимок так просто.

Я очень рад, что Рохелио Гусман, основной участник Jest и инженер из Docker, приедет на ReactiveConf в этом году. Он расскажет нам больше о Jest Snapshots и будущем тестирования. Надеюсь, у него есть идеи, как, наконец, сделать автоматические тесты дешевыми в написании и поддержке!

Если вы так же взволнованы Jest Snapshots, как и мы, приобретите свой билет сегодня! Сэкономьте 10%, используя код скидки Guzman4Reactive при оформлении заказа.

- Сэмюэл Хапак и команда ReactiveConf