Як модернізувати тести в бази коду ReactJS без тестів

Тестування програмного забезпечення та полегшення його виконання цікавлять мене вже кілька років. Цей інтерес тепер більше зосереджений на інтерфейсних програмах, які раніше були. Точніше, для програм reactjs. Минуло кілька місяців, як я занурився в код reactjs п’яти-десяти років тому, який дає мені знання та виклики.

Я особисто розробляю код reactjs вже кілька років; один із перших проектів з відкритим кодом, яким я поділився, називається testable . Він був випущений приблизно в 2020 році, і з того часу я присвятив частину свого навчання reactjs.

Останнім часом я працював над іншими проектами з відкритим вихідним кодом, які зосереджені на тестовій частині таких речей, як json-tool і text-tool ; обидві програми мають відкритий вихідний код і розгорнуті на Snapcraft. Крім того, я часто запускаю експерименти в репозиторії під назвою reactjs-playground . Це місце, де я експериментую з функціями reactjs і присвячую цьому свої навчальні години. Досвід, який я отримав за ці роки в проектах із закритим і відкритим кодом, дав мені основу, яка дозволяє мені визначити деякі загальні підводні камені та переваги.

Підводні камені

Розробники, які долучаються до шаблону та інструментів reactjs, розуміють, що будівельні блоки, які пропонує бібліотека, легко зрозуміти та скласти. Найабстрактніша концепція компонента може бути використана для швидкого створення інтерфейсів користувача. Однак це також може бути джерелом помилок, коли йдеться про структуру ієрархії компонента. Декомпозиція систем - це предмет , який вивчається роками.

Великі компоненти

Розмір єдності абстракції в програмному забезпеченні також був предметом дискусії; деякі стверджують, що методи та класи повинні мати невелику кількість рядків, тоді як інші вважають за краще мати більший, добре структурований фрагмент. Як і в будь-якому програмному проекті, незалежно від розміру, я маю намір віддати перевагу розміру, який надає більше контексту та створює менше навантаження на когнітивне навантаження під час читання коду.

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

Скільки стрибків я повинен зробити, тим більше мені потрібно тримати в голові контекст і інформацію; це стає важко, зберігаючи базу коду. Декомпозиція цих компонентів є проблемою, однак її потрібно враховувати для кращого обслуговування бази коду.

Глобальна держава

Для професійного розвитку глобальна держава є основною вимогою; для додатків reactjs це нічим не відрізняється. Користувачі програми легко помітять глобальний стан. Якщо ви купуєте щось і додаєте продукт у свій кошик, ви можете побачити кількість доданих вами товарів; це глобальна держава.

У програмах reactjs колись широко використовуваний пакет редукції глобального управління станом тепер зменшив його використання на користь менших контекстів навколо кордонів програми. Однак спільнота розділила різні думки щодо необхідності використання redux для глобального управління станом; це призвело до кількох блогів на цю тему:

• Вам не слід використовувати Redux для програми React .
• Чому вам більше не потрібен Redux?

Незважаючи на відмову з боку спільноти, react-redux, бібліотека, яка використовується для прив’язки redux до компонентів reactjs, отримала поширення за останні п’ять років відповідно до тенденцій npm . 1 лютого 2025 року кількість завантажень, показаних у npm для redux, становить 6 752 764.

Якщо вам цікаво, яка альтернатива цьому, тоді відповіддю буде контекст reactjs і хуки із запитами.

Для додатків, які залежать від пакета redux, само по собі вийти з нього складно. Глобальний стан є однією із залежностей, які знижують можливість тестування програми. З мого досвіду, необхідний глобальний контекст часто супроводжується підвищеною складністю знань предметної області. Хоча ви можете протестувати лише окремий компонент або фрагмент вашої програми, ви не зможете це зробити, не поділившись глобальними залежностями, яких вимагає цей фрагмент.

Переваги

Прийняття reactjs для корпоративних додатків на момент написання цієї статті було правильним рішенням з точки зору зручності обслуговування (незважаючи на критичний момент, який мав Facebook, коли він змінив модель ліцензування бібліотек). ReactJs забезпечує зворотну сумісність для API, які більше не використовуються, що робить довгострокове впровадження однією з ключових переваг.

Контексти

Начебто компонентів недостатньо як абстрактної концепції, яку можна обійти, контексти також є однією з переваг, яку надає reactjs щодо тестування. Я детальніше розповім про цю тему в публікації в блозі, присвяченій контекстному тестуванню reactjs . Рівень інкапсуляції, який надає контекст reactjs, є однією з ключових переваг для модернізації тестів і включення рефакторингу в базах коду reactjs.

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

Тести на модернізацію

Враховуючи такий список досі, ми сподіваємося, що частина тестування стала зрозумілою, що залежить від того, як структуровано вихідний код і як організовано межі програми. Однак, незважаючи на те, що код тестування залежить від робочого коду, подвійні тести можна використовувати, щоб допомогти розмежувати область. Розумний процес для модернізації тестів складається з кількох простих кроків.

1. Напишіть простий тестовий приклад для бажаної функціональності.
2. Запустіть тест і побачите, що він не вдається.

2.1. Тест пройшов?

 2.1.1 - Yes → Check if the feedback is correct 2.1.2 - No → Provide the dependency without questioning

3. Поверніться до 1.

Зауважте, що: описаний тут підхід подібний до того, що описано як тест на характеристику, описаний Майклом Фізерсом у

Ефективна робота з успадкованою книгою кодів.

Поява LLM може також надати розуміння під час написання перших тестів і модернізації бази коду без будь-яких тестів. Кожен крок у цій стратегії має бути повторюваним; також можна поєднувати різні стилі TDD. Запропонований підхід полягає в тому, щоб не припиняти робити все й модифікувати всі можливі тестові випадки та всі можливі проблеми, які є в кодовій базі, це гра-головоломка. Кожна перевірена функція є частиною, яка вписується в головоломку.

Той самий підхід пропонується для рефакторингу. Розробники повинні мати можливість постійно рефакторингувати частину коду. Це не інший проект, і він не спрямований лише на те, щоб йому присвятити. Його головна мета — зробити кодову базу кращою, ніж вона була. Ітеративно. Є кілька аспектів, які можна використовувати для модифікації тестів у кодових базах, у яких їх немає:

• Виправлення помилки – це можливість познайомитися з кодом і зрозуміти, як він поводиться. Виправлення помилки є частиною проблеми, однак це також можливість охарактеризувати розглянуту програму.
• Впровадження нової функціональності – це те саме, що виправлення помилки, однак підхід дещо змінюється. Це той самий підхід, який запропонував Кент Бек: «Зробіть зміни легкими, а потім зробіть легкі зміни». Нова функціональність — це місце, яке відкриває кодову базу для внесення змін перед впровадженням нової функції.

В основі цього підходу лежить процес навчання; враховується кожен крок вивчення кодової бази.

LLM

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

Візьмемо як приклад Testable ; це програма, написана більше п’яти років тому на reactjs і використовує фермент для тестування. Для сьогоднішнього стандарту бібліотека, яка взяла верх, є vitest або jost разом з бібліотекою тестування. Щоб модернізувати тестові випадки для тестування та скористатися перевагами LLM, ми можемо використовувати другий пілот, який допоможе нам у важкій роботі.

Testable складається з гейміфікованого досвіду, який має стан, рівні та прогрес користувача через різні виклики. Компонент, описаний на наступному зображенні, використовується для показу діалогових вікон і переходу вперед в історії досвіду. Використовуючи Copilot для vscode, я попросив його написати тест із робочим кодом, який нас цікавить:

Після завантаження запитання та аналізу коду він надає відповідь.

Разом із відповіддю Copilot помітив, що я ще не використовую бібліотеку для тестування, і пропонує зробити це, а після цього буде показано згенерований тестовий приклад. Запуск тесту, як показано, робить тест непрохідним і позначає його червоним.

Цей пункт важливий, оскільки він показує, що потрібно враховувати додаткові налаштування, а Copilot не міг це зрозуміти. Вони такі:

• Імпорт не правильний; його потрібно виправити, щоб вказувати на правильний файл.
• Параметри вмісту неправильні; файл не вдалося зробити вміст дійсним для тестового випадку.

Послідовність, описана раніше в цьому розділі, також застосовується тут. Цикл зворотного зв’язку тепер полягає в тому, щоб почати виправляти ці проблеми та запускати тести, доки не завершиться цикл TDD.

Ресурси

• Характеристичний тест