Подготвяме се за Assert(js), първата по рода си конференция, фокусирана върху тестване за разработчици на JavaScript, и имаме невероятен списък с подредени лектори. Те вече предизвикаха няколко разговора в Twitter, така че решихме да съберем панел в HashBang Show, за да дадем предварителен преглед на това, което конференцията предлага!

Панелът включваше:

Покрихме много теми, свързани с тестване, както общи, така и специфични за JS. Включете се в епизода по-долу и превъртете надолу за акценти в дискусията и повече подробности за конференцията!

Ето няколко акцента:

Произходът на подигравки / тестови дубли

Джъстин имаше интересна част от историята за произхода на мокове/шпиони/проксита/фалшификати/тестови двойници:

  • Те бяха въведени за първи път в края на 90-те години от членове на London Extreme Programming Group.
  • Хора като Стив Фрийман и Анет Прайс ги въведоха като механизъм за изследване на наследен код.
  • „Представете си голяма наследена кодова база като Звездата на смъртта и бихте прехвърлили фалшив обект като жило за свързване и всеки път, когато бъде взаимодействано с него по някакъв начин, ще експлодира.“
  • Това беше начин да ги информират как аргументът е взаимодействал с „непознатия, объркващ обект на тест“.
  • Хората от лондонската XP група продължиха да използват тестови двойници като начин за получаване на обратна връзка за дизайна, когато използват TDD за проектиране на нова система
  • … и тук възниква голяма дискусия за това как често се злоупотребява с тях.
  • Джъстин препоръчва да прочетете „Разрастване на обектно-ориентиран софтуер, ръководен от тестове“ от Стив Фрийман и Нат Прайс

„Тестовата пирамида“

  • „Тестовата пирамида“ е концепцията, че автоматизираните тестове трябва да се състоят предимно от единични тестове, които формират основата на пирамидата, след това по-малко интеграционни тестове, които формират средата, и само малък брой от край до край тестове, които управляват потребителския интерфейс.
  • Кент: „Пишете тестове. Не много. Предимно интеграция.»
  • Глеб: Формата на пирамидата всъщност не се определя от нашите нужди, но се определя от инструментите, с които разполагаме сега.
  • „Увереността се увеличава, докато се изкачвате по пирамидата“, но удобството намалява.
  • Но Джъстин има алтернативен възглед: той открива, че противно на това, което повечето хора очакват, чистите модулни тестове, които осмиват всичко в изолация, всъщност правят осигуряват висока увереност. Неговата причина е, че, както е обяснено в тази статия, единичното тестване е „кодиране внимателно“ и това води до изграждане на по-висококачествена система.

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

  • Браян за тестове от край до край:

Неуспехът на тестването от край до край е: когато има предпоставка [за състоянието, което искате да тествате], след това използвате потребителския интерфейс, за да генерирате състоянието за друга предпоставка, и това е основно мястото, където всичко се обърква... Ако сте тествайки функционалността на пазарската количка, използвате ли потребителския интерфейс, за да посетите административната област, за да генерирате 100 продукта, за да добавите след това тези продукти в пазарската количка? Абсолютно не. Това, което препоръчваме, е следното: имате няколко незабелязани интеграционни теста, които тестват наистина критичните области на приложението. И след като сте направили това, след като сте установили, че това работи, имате 100% увереност, че никога повече няма да използвате тази част от потребителския интерфейс. Това е основно философията на Cypress и това го прави много различен инструмент, защото от архитектурна гледна точка ви позволява да правите такива неща.

Какво е различното при тестването в JavaScript

Тестване на асинхронен код:

  • Инструментите, с които разполагаме през последните години, подобриха много асинхронното тестване, напр. обещания и async/await.
  • Голяма част от причината за асинхронния код е I/O, който трябва да живее в периферията на приложението, но „месото и костите“ трябва да са бизнес логиката и разделянето на двете е наистина полезно.

Какво да очакваме

Участниците в панела очакват с нетърпение да се срещнат и да разговарят с присъстващите относно техните подходи и предизвикателства за тестване. Ние насърчаваме всички да се възползват от възможността да говорят с всички лектори в това, което ще бъде малка и социална среда. Така че елате в Сан Антонио и чуйте повече за темите, обхванати в този епизод, с напитки и храна!

Напомняне, ако сте пропуснали специалното съобщение за промоционален код от Робърт:

Използвайте промоционалния код HASHBANG при напускане и получете 20% ОТСТЪПКА от редовната цена на билета!

За билети и информация за конференцията посетете https://www.assertjs.com/

Надяваме се да ви видим там!

Първоначално публикувано на www.okgrow.com.