Прост въпрос за начало: Защо тестваме кода си? Най-простият отговор е да спечелим колкото можем повече увереност, така че а) кодът ни да работи според очакванията, и б) нашите потребители могат да изпълнят задачите, които очакват.

Но има много по-голямо несъответствие/сива зона между тестването за задния и предния край. Докато задните части обикновено се свеждат до работни потоци за вход/изход, потребителският интерфейс е склонен да бъде... добре, по-променлив и сложен, като се имат предвид пътуванията на потребителите, които са нелинейни и често се пресичат, докато системата расте.

С течение на времето интерфейсите са развили два основни типа тестове, за да помогнат в борбата с тази нарастваща сложност: интеграционни тестове (напр. testing-library) и e2e тестове ( напр. драматург). И двете имат своите плюсове и минуси и заслужават своето място в стека за тестване. 👌

Но въпреки това, повечето екипи за разработка имат един продължителен, болезнен въпрос без отговор: КЪДЕ ТЕСТВАМЕ ЕТИКЕТИ НА UI? (И друго копие/текст също?) Ако не получат правилния отговор, това неизбежно ще доведе до много небрежни и/или „излишни“ тестове.

Важно е да разбием по-дълбоко този фундаментален въпрос (ала *5 защо), преди да предложим реално решение за него. Всеки отбор трябва да попита:

В: Защо искаме да тестваме етикети? Имаме ли нужда?

  • Помислете добре за това. Да, на теория е чудесно да се тества ВСИЧКО, но има висока цена, свързана с тестването, както внедряването, така и поддръжката. Помислете за колата си - не би ли било по-безопасно да я водите всеки ден на механик, за да я тества? Ами да, но никой не го прави, защото цената е твърде висока, както време, така и пари. Дори само ежедневна проверка наоколо би била от полза, но повечето от нас никога не го правят. Ако от време на време има удар или драскотина, така да бъде! Когато го хванем произволно, тогава ще се справим с него.
  • Някой текст е по-важен за тестване от друг. Приоритизирането на списък с тях може да помогне.

Въпрос: Каква е връзката между работата между промяната на етикет и актуализирането на теста за него?

  • Ако винаги е едно към едно, тогава наистина ли е полезно или просто синхронизира време на натоварена работа?

Въпрос: Колко често се променят етикетите? (Колко гъвкави/променливи трябва да бъдат етикетите?)

  • Да приемем, че отговорът на този въпрос обикновено е „по всяко време“ или „често“. Защото всъщност фактът е, че продуктовият мениджър трябва да може да прави пазарни проучвания и да се връща при екипа за разработчици с ВСЯКАКВА козметична промяна на продукта, включително всеки текст. Когато и да е.

Въпрос: Колко сме склонни да рискуваме да счупим тест (т.е. да спрем внедряването!), когато етикет се промени?

  • Това е критичен разход за преценка! Сериозно. Много тестови костюми се разпадат, когато започнат да се провалят, но никой от екипа не се интересува достатъчно, за да поправи „несъществените“ повредени тестове — тъй като все пак работят върху нови, критични функции нали?! Превъртете няколко седмици напред и фалшиво положителният шум става по-труден за откриване, така че доверието в системата за тестване започва спираловидно да намалява; и качеството остава на заден план, тъй като внедряването се превръща в тъжен ритуал на суеверие и поведение като „болно“, за да се избегне отстраняването на проблеми при лошо внедряване. (Да, виждал съм това да се случва много пъти.) Не позволявайте на етикетите да правят това с вашия проект.

Добре, мисля, че въпросът е ясен. Първо, помислете внимателно за тестване на етикети/текст!

Сега, да приемем, че сте направили списък с приоритети на критичните етикети в системата - например CTA бутони, заглавия на страници и бутони за навигация. Страхотен! Сега… трябва ли да ги тестваме в E2E (т.е. ниво на браузър) или интеграция (т.е. ниво на уеб компонент)?

За да отговорим на това, нека проучим още един важен въпрос – дали етикетите всъщност са: A) sконфигурация на системата или B) бизнес логика? Ето няколко ключови елемента, които трябва да разгледате внимателно:

  • Повечето големи системи приемат i18n, което означава, че етикетите вече не се дефинират на линия, а се предоставят чрез извикване на функция, за да се върне правилният низ на езика. Например в React можем да направим нещо като този код: <Button label={i18n("Submit")} />
  • Трябва ли да изберем компоненти за тестване чрез техния етикет, който нашите потребители действително ще видят, или по-стабилен test-id?

Според моя опит тази рамка се е сработила най-добре (като се вземат предвид всички):

  • ЕТИКЕТИТЕ СА КОНФИГУРАЦИЯ (тъй като не са логически и не са твърдо кодирани; вместо това се предоставят чрез конфигурационни данни и ще се променят в зависимост от системата на потребителя, която ги изпълнява).
  • Следователно приоритетните/критичните етикети трябва да бъдат тествани в E2E (не интеграция); това е мястото, където тестваме пътуването/изживяването на потребителя и където браузърът може да бъде конфигуриран да работи на множество езици. Базата на проекта за тестов пакет трябва да бъде проектирана с прости конвенции за максимизиране на DRY кода/минимизиране на персонализирането за собствените „персонализирани“ етикети на всеки език.
  • Интеграционните тестове трябва до голяма степен да игнорират етикети/текст. (Ако искате... можете да изберете да преброите с „шпионин“ колко пъти се извиква вашата i18n функция. Но това най-вероятно е детайл от изпълнението, който дори не си струва да се проверява!)
  • Както E2E, така и интеграционните тестове трябва да избират изобразени уеб компоненти само чрез стабилен test-id, за да се сведе до минимум количеството счупване на пакета от тестове, като в противен случай се избира нестабилен текст на етикета (т.е. select('[test-id=buy-now]'), а не select({text: 'Buy Now!'})).

Какво мислите, съгласни ли сте? Надяваме се, че това ще помогне на вашия екип да разбере по-добре плюсовете и минусите. Уведомете ме в коментарите.

Можете да ме последвате в Twitter и YouTube. Нека продължим интересните разговори за разработката на Sr JS заедно!