Ну, тестування так тестування. В коментарях підказали розказати про good enough test.

Як і будь-який розробник, я не те шоб сильно полюбляю писати тести. Але чітко розумію їхню необхідність, особливо на великих продуктах. Як мінімум для відлову регресій, бо наприклад ота легендарна "реюзабельність компонентів" реальна, і в дійсно великих кодбазах цілком собі існує. І зламати пів продукту, "пофіксавши" компонентик — як два байти переслать.

Тому я додаю тести. Зауважте — не пишу, а додаю. Бо я манав то робити руками. Для цього є тупа жалізяка за 20 баксів на місяць, хай відробляє.

Так от, що тестую? Критичні точки. Я не покриваю 100% коду тестами, це безглуздо. Зазвичай я тестую happy path і unhappy path. А едж-кейси покриваються окремо, в разі, якщо зловлять якусь багу. У нас взагалі практика така — зафіксав багу, додав тест.

Звичайно ж, для того, аби написання тестів не приносило смутку й журби, треба й по іншому писати свій код. Наприклад, розносити усе в дрібніші юніти. А ще — розділяти відповідальності.

Я стараюсь виносити усю логіку з React-компонентів в окремі хуки, лишаючи в ньому суто рендер від отриманих значень. Це дозволяє мені тестувати на двох рівнях: в хуку я тестую результуючий зліпок стану, який це хук продукує, а в UI просто перевіряю, чи вірно відображається розмітка в залежності від вхідних даних.

Ті ж хуки можна мокати в довільному порядку, і я можу писати тести для чітко детермінованих ситуацій, перевіряючи правильність розрахунків всередині стейту. А ще я можу замокати цей стейт-хук і тестувати відображення від передбачуваних статичних "снепшотів".

Якшо коротко, я намагаюсь звужувати скоуп своїх тестів. Тоді я розумію, що саме треба протестувати, і все зайве відкидаю.

Повертаючись до good enough test — він повинен покрити основні кейси, успішні/неуспішні, та перевірити правильну залежність результату від вхідних даних. І він має бути сфокусований.

Якщо я тестую свій хук, мої тести не мають перевіряти інші хуки, вони їм мають довіряти. Якщо я тестую UI-компонент, я маю перевірити чи все на місці, і чи все натискається.

Умовно, якщо у мене в компоненті кнопка, яку натискаєш, і там щось показується, то я тестуватиму це так:

На рівні стейту: чи зміниться фінальний стан після виклику певної функції;
На рівні UI:
1. Чи викличе кнопка певний колбек
2. Чи покаже юайка певний елемент, якщо у вхідному стані є відповідне значення

Це окремі ізольовані тести. Бо інакше це вже e2e, а то вже геть інша історія, тим бажано займатися спеціально навченим людям.

І так, ці тести генеруються ШІ. Але для цього треба надати купу інструкцій, які пояснюють що треба, а що не треба. Сам по собі ШІ генерує таку відверту дич, шо на голову не налазить. Тому не думайте, що якщо просто написати "напиши мені тести", він відтестує то шо треба.

Зокрема після останнього оновлення Cursor та ChatGPT мені довелось переробляти інструкції, і все одно ця жалізяка продовжує ігнорувати певні вказівки. Наприклад, у мене чітко прописано "НЕ МОКАЙ НІЧОГО, СКАТИНЯКА", але воно мокає ВСЕ. Доводиться руцями чистити. Але то таке, приїду, займусь тим питанням, буду тюнити далі.

Якщо підсумувати, то вийде шось таке: розробник повинен писати тести на свій код. В моєму випадку це для запобіганню регресіям. У когось буде інша мотивація, може тімлід — проповідник TDD, хтозна. Але суть в тому, що в тестах немає нічого поганого, навпаки, вони дозволяють заощадити час, ресурси й нерви в тривалій перспективі.

Інше питання — як продати цю ідею бізнесу. Тим паче, що зараз ще й вайбкодинг додався, і створюється ілюзія блискавичної розробки. Виглядає круто — нема тестів, вайбкодиш, продукт ледь не за вечір на проді.

А потім раптом вже крадеться піздець з своєю усмішкою хижой. Простуда, геморой, чіряк на сраці, запльована підлога, лікарі, від шприца гематоми і могила…

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

А, і ще одне — тести стає набагато легше писати, якщо ти розумієш, що це, для чого, і який має бути результат.