Пропоную наступний челендж:
1. Прочитати статтю: https://blog.logrocket.com/css-if-function-conditional-styling.
2. Охрініти.
3. Вихрінити.
4. Задонатити кілька гривень на Mavic для 184 навчального центру.

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

#думки_вголос
Вчора на ламповій тусовці очікувано мова зайшла про вайбкодинг, якість коду і місце людей серед усього цього балагану.

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

Зараз код писати може будь-яка більш-менш нормальні модель. Однак саме писати. ШІ може згенерувати працюючий код, але не передбачить і не пояснить наслідки цього коду для проєкту. Він може пояснити як код працює, але як впливає — це вже на межі фантастики.

Вміння читати код, саме читати, а не пробігатися по назвах функцій і змінних — це, фактично, єдиний достовірний спосіб розуміння архітектури продукту. Створювати код нині це рідкісна розкіш, зазвичай ми входимо в уже написане.

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

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

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

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

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

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

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

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

Вчіться читати чужий код. Не просто очима, а пропускати його через фільтри недовіри, сумнівів, скепсису та власної технічної і не тільки експертизи. І тоді ніякий ШІ нікого не замінить.

До речі, а ви що думаєте з цього приводу?

@babichdev

Товариство, вітаю вас з початком нового тижня, а себе — з початком відпустки.

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

Хіба завтра ще заскочу, бо буде нагода, а так — наснаги вам, сил та натхнення на цей тиждень.

З прекрасним настроєм
Цьом вам у лобіка.

Ваш Бабіч.

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

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

Тож дякую вам за вас, товариство, і прямую стрімголов в новий рік життя! Побачимо, на які здобутки він нас із вами надихне ;)

Якщо ж ви відчуваєте бажання привітати мене зі святом, ви можете зробити це донатом на Mavic 3 для 184 навчального центру. Можна 38 гривень, можна 12, можна 8, можна 1208, можна 1987, можна й 2025 ) Буду вдячний за кожну гривню!

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

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

JavaScript це найкраща мова для веброзробки, а кому він не подобається — той [object Object]

@babichdev

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

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

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

Домовились?

…треба було грошима брать…
чухає голову

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

Мова про Internet Explorer. Так, так, той самий IE, про який багато з вас знає лише з жартів про "бравзер для скачування Chrome". Але колись він міцною хваткою тримав ринок.

Саме в IE3.0 зʼявилася повноцінна (на той час) підтримка CSS, без якого сучасна веброзробка навіть не уявляється. І саме завдяки IE ця технологія набула такого поширення та популярности.

До речі, тривалий час саме IE був "тим самим" бравзером для MacOS, про що я вже свого часу писав. Ну й годі казати, що для мільйонів користувачів Microsoft Windows він був єдиним бравзером. Не через те, що інших не було, а через надзвичайно вдале рішення — інтегрувати його в систему. Навіщо тобі щось інше, коли віконце у дивовижний світ Всесвітньої Павутини вже тут, ось, працює, і майже весь Інтернет "найкраще працює в IE"?

Беззаперечний переможець Перших Бравзерних Воєн, він спочивав на лаврах, однак час не стояв на місці, і доволі швидко учорашній переможець, що тріумфально витіснив Netscape Navigator, опинився в ролі аутсайдера.

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

А коли стало зрозуміло, що відставання вже занадто критичне, було вже пізно. На ринку зʼявилися нові гравці, молоді, зухвалі, що не боялися експериментувати, швидкі, рішучі. І корпоративна машина виявилася просто не в змозі наздогнати цей потяг.

Однак не варто забувати і його здобутки. Без XHR та innerHTML ми б не мали динамічних сторінок та AJAX, що стали підґрунтям для буму SPA. Без ContentEditable ми б не отримали Google Docs та Notion. Та й перша робоча імплементація CSS Grid зʼявилася теж в IE, а саме в IE10.

Однак, попри стрімке падіння на ринку популярних бравзерів, IE продовжував своє життя, хоч і без розвитку на мільйонах корпоративних компʼютерів, ба більше, неймовірна кількість спеціалізованого софту, наприклад банківського, була написана в повній інтеграції з тим же ІЕ6 через інтеграцію з ActiveX.

Офіційною датою смерті ІЕ вважається 15 червня 2022 року, коли Microsoft припинила підтримку IE11.

І хай там як, цей бравзер заслужив своє місце у залі слави Інтернет. Хтось памʼятає його як першого провідника до світу вебу, хтось як нестерпний біль, на який треба було постійно зважати та підтримувати в буремні 2010-і, хтось — як бравзер, завдяки якому доступ до інтернету став відкрився для мільйонів та мільйонів користувачів.

А хтось дивитиметься глибше і розумітиме, що без нього сучасна веброзробка була б геть зовсім іншим явищем. Кращим? Гіршим? Нам того не знати. Але подякувати Internet Explorer усе-таки варто. Бо і його здобутки, і його помилки крок за кроком, цеглинка за цеглинкою збудували для нас цей дивовижний світ веброзробки.

@babichdev

Товариство, маленьке оголошення!
26 серпня я буду в Києві, в якості запрошеної абізянки на IT StandUp: Fails Night — благодійному вечорі, організованому компанією Brainstack, де відверто і з дуже серйозними писками поговоримо про те, що пішло не за планом.

Будем ділитися там своїми шляпами і провтиками, а ще буде відкритий мікрофон, тому ви теж матимете нагоду ще разочок опозоритись з вашим факапом.

В програмі:
• Жонглери!
• Цікаві факап-історії!
• Фокусники!
• Професійний нетворк та знайомства!
• Стрептиз!
• Аукціон та чаріті-лотерея!
• Донати — на підтримку збору «Мережа Трійки» від DOU!

26 серпня, 18:00
Kooperativ Rooftop

Квитки — за донат
https://eventmate.app/events/share/it-standup-failsnight

До зустрічі!

Хто з нас може сходу відповісти що таке каскадність в CSS? Мало хто. Ба більше, я впевнений, що більшість не розрізняє поняття CSS та стилів. Але не переживайте, я сьогодні не буду вас за це соромити, бо й сам тривалий час не приділяв цьому відповідної уваги. Натомість давайте краще разом в цьому розберемось.

В першу чергу варто зафіксувати, що Україна не Росія, а CSS не стилі. А інструмент для структурованого їх опису. Стилі ж — це безпосередньо правила, які застосовуються до елементів. Тобто CSS це те, що ми пишемо, стилі — те, що бравзер мастить на DOM.

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

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

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

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

До речі, чому саме каскад? Якщо уявити собі цю схему як водоспадик, то виглядатиме вона так:

[user-agent styles]
 ↳[user styles]
   ↳[author styles]

І в такій ієрархії пріоритет надається стилям, що знаходяться нижче за каскадом. Така собі спадна ієрархія.

Дуже важлива ремарка: це класична модель без !important. З ним user styles важливіші за author styles. Але я це не розглядаю детальніше, бо за !important треба звільняти з доганою і відбирати назавжди ліцензію на написання CSS.

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

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

Якщо ви досі не поставили вогник і не поширили цей допис, знайте — я на вас образився.

А чого ж я вжив вираз "класична модель"? Бо тепер у нас є ще один нюанс, на який треба звертати увагу, і це надзвичайно потужний інструмент для керування каскадом саме нами, розробниками.

Мова йде про @layer. По суті, це ще один рівень в межах origin, який дозволяє нам точніше групувати визначення і, що найголовніше, керувати порядком застосування цих груп. Що важливо, специфічність в шарах також ізольована, тому важкий селектор з одного шару може бути дуже легко перебитий легеньким селектором з іншого:

@layer base, override;

@layer override {
  p { color: red; }
}


@layer base {
  #foo { color: lime; }
}

В цьому випадку текст <p id="foo">hello</p> буде не зелений, а червоний, хоча, як ми знаємо, id набагато важчий за селектор тега.

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

Я особливо оцінив цей підхід у дизайн-системах: стилі легко розбивати на логічні групи — tokens, base, typography, components, overrides. І завжди зрозуміло, в якому порядку вони застосуються, без страху, що десь у глибині з’явиться монстр-селектор на десяток класів і ID, згенерований JavaScript, і доведеться з ним воювати.

***
Специфікації W3C
CSS Cascading and Inheritance Level 4 — Cascading Order
CSS Cascading and Inheritance Level 5 — Cascade Layers

Документація MDN
Cascade and inheritance
Cascade layers

Статті людською мовою
Getting Started With CSS Cascade Layers
CSS Cascade Layers

***
А ви як, пробували вже, використовували? Чи чуєте вперше, і вже не можете дочекатися, аби запушити це в прод? Розказуйте.

@babichdev

Так, товариство, якщо б хто хотів зустрітися наживо у Львові, то сьогодні від 19 години буду в пабі "Горобець", що за адресою Театральна 23.
Там буде чергова лампова тусовка, тож підходьте, буду радий бачити!

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

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

Приємного читання!

https://una.im/5-css-functions/

Найкращий в світі.
З Днем Прапора, товариство.

А ще 23 серпня вебспільнота відмічала так званий Internaut Day — День Дослідника Інтернету. Він присвячений усім, хто бодай якось дотичний до розвитку Мережі. І з цією датою я вас, друзі, хоч і дещо запізно, вітаю.

До речі, дату 23 серпня було обрано хибно, і ніхто вже не дасть відповідь, чому саме. Справа в тому, що 23 серпня 2016 року Facebook опублікував повідомлення, в якому зазначив, що "цього дня 25 років тому веб став відкритим для світу" та подякував Тіму Бернерсу-Лі за те, що зробив світ відкритішим та повʼязанішим.

Проте того ж дня сам Бернерс-Лі обурився цьому повідомленню, бо дата була просто напросто видлубана з носа.

А насправді ця подія відбулася 6 серпня, коли пан Тім Бернерс-Лі в мережі Usenet, а саме на форумі alt.hypertext опублікував опис свого проєкту World Wide Web, тим самим відкривши світу ідею повʼязаної павутини сторінок та поставивши за мету доступності будь-якої інформації з будь-якої точки Мережі.

Що робить цю публікацію дійсно визначною? Це не був просто опис ідеї, не просто документ. Це був заклик. Заклик до спільноти приєднатися до розвитку проєкту. Фактично Бернерс-Лі відпустив своє дітище, WWW, у вільне плавання та передав його до рук ентузіастів по всьому світу.

І в той час, коли Всесвітня Павутина робила свої перші кроки до незалежності доступу до інформації, на іншому боці планети до своєї Незалежності крокувала Україна.

Ми, українські веброзробники, багато чим завдячуємо саме серпню 1991 року. Без тієї публікації не постало б відкритого вебу, яким ми його знаємо, а без проголошення Незалежності не постало б сучасної України.

І ми не були б саме українською спільнотою веброзробки. Можливо, ви б зараз читали блог Сєргєя Бабіча "Удівітєльний мір вебразработкі". Тьху, аж млосно стало.

Але сама ідея Незалежності настільки глибоко сидить в нас самих, що цього просто не могло не статися. Так, наш шлях до неї і досі не скінчився, ми досі виборюємо її. Ми ледь не втратили її, та знову стали на захист. І якщо тоді, 1991 року, ми, як і усі інші новонароджені держави, відбулися економічною кризою, то нині платимо свою ціну кровʼю.

І ми не повинні цього забувати у жодному разі. Бо ціна ця висока і незворотня.

Тож із Днем Незалежності вас, товариство, і дай нам бог так само вітати одне одного із цим святом і за пʼятдесят років у так само вільній та незалежній Всесвітній Павутині.

Товариство, хочу запросити вас на другий DOU Picnic, що відбудеться вже цієї суботи в Києві! Якшо ви ще досі вагалися, чи варто йти, скажу — варто.

Мені дуже сподобалась ідея великого, грандіозного, будьмо відверті, нетворкінгу. Особливо формат — такий собі айтішний ярмарок із забавами. І цього року я теж його відвідаю. Зокрема, аби побачитись із вами.

Тому не гайте часу, беріть мерщій квиточок, тим паче, що як і торік, пікнік буде благодійним: усі кошти підуть великий зібр для 3 штурмової бригади разом з «Мережею Трійки».

Мінімальний внесок — 1000 грн (ціна діє до 29 серпня).

🎟 Придбати квиток

У програмі будуть:
– виступи на великій сцені і ретро-стейдж
– Job Speed Dating
– фотозони, фудкорт
– концерт і стендап
— і можливість зловити мене та нарешті сфоткаться ;)

🔎 Деталі, спікери, квитки — на сайті події

P.S. Якшо шо, я вже в Києві, як хто хоче зустрітися — пишіть. Завтра от в кіно планую вдень сходить.

Був оце ж учора на «факап-вечорницях» від Brainstack. Трохи поділився з глядачами тим, як штучний інтелект так підставив мій PR, що я наловив пісюнів коментарів від інжиніринг-менеджерки. Або як я власноруч втопив офер мрії, коли на дзвінку з рекрутеркою видав три відра крінжі. Було весело.

Але зараз я хочу поговорити не про ці історії, а про те, як нам треба ставитися до помилок в принципі.

Я не люблю слова "факап" чи "фейл". Від них якось несе приреченістю. Як на мене, в розробці усе, за що тебе не звільняють учорашнім днем — не факап, а так, пройоб. От пропоную надалі цей термін і використовувать.

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

Спочатку життя навчило мене визнавати помилки, і лише згодом воно мене навчило аналізувати помилки та робити висновки — і, що головне, враховувати їх у майбутньому

В розробці це так само важливо, як і будь-де. Бо якщо на дрібних косяках не робити саморефлексію, то одного дня пройоб таки стане факапом рівня "Срака-мотика". А воно нам треба?

А зараз я трошки відступлю від теми. Учора в готелі випадково ввімкнув «Аполон-13» з Томом Генксом. Ніколи його не бачив, і тут раптом втягнувся по самі вуха. Фільм крутий, але ще цікавіша сама історія програми.

Першою дісталася Місяця одинадцята місія — «Аполон-11». А все, що було до того, для стороннього глядача — одна суцільна низка невдач. «Аполон-1» взагалі закінчився трагедією: під час випробувань на стартовому майданчику згорів увесь екіпаж. Інші місії зі сторони теж могли виглядати невдачами: то не злітали, то вибухали, то ламалися по дорозі.

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

До речі, не завжди наші факапи — саме наші. Причина, що призвела до майже катастрофи з "Аполон-13"? Одна маленька бракована котушка в електричній схемі в системі подачі кисню.

Тож, по-перше, сприймайте робочі пройоби не як кінець світу, а як шанс вирости.

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

Підсумуємо: пройоб без аналізу — це запрошення до наступного провалу, а от пройоб з ретроспективою — перетворюється на досвід.

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

По-друге, я до вас по ділу. Маю запит від Житомирського військового інституті імені С.П. Корольова допомогти придбати деякий інвентар для забезпечення навчального процесу для майбутніх офіцерів. До речі, так, на відео — частина підготовки курсантів.

Так от, щоб була можливість і далі проводити таку підготовку, ми з вами можемо швиденько зібрати кошти на наступне:

Граната Pyrosoft РГД Pyro-5
90₴ × 120шт = 10 800₴

Димова граната Pyrosoft П-18 “Актив”
190₴ × 60шт = 11 400₴

Дим страйкбольний M18 White
105₴ × 60шт = 6 300₴

Разом 28 500₴

🔗 Банка
send.monobank.ua/jar/AeXQ6YRf2X

💳 Карта
5375411202918178

Дякую за кожну гривню і цьом вам у лобіка!

P.S. У мене вже є на руках відеозвіти з попередніх зборів на РЕБ та на Mavic, дістанусь хати — викладу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так, товариство, п'ятнична забава — якщо ми сьогодні до кінця дня закриємо збір на тренувальні гранати для Житомирського військового інституту , офіційно обіцяю додати до реакцій "палець вгору".

То як, 👍 чи не 👍?

🔗 Банка
send.monobank.ua/jar/AeXQ6YRf2X

💳 Карта
5375411202918178

Там 8,5к лишилось зібрати