Пиши тести ПЕРЕД кодом! TDD - розробка через тестування
ฝัง
- เผยแพร่เมื่อ 16 พ.ค. 2024
- Розробка через тестування (TDD) це дуже крутий підхід по розробці програмного забезпечення. Тести які пишуться перед кодом допомагають краще сфокусуватись над задачами. Він може стати трампліном в рівні тебе як спеціаліста. В цьому відео я пояснюю ідею навіщо писати тести перед кодом і власний досвід його використання
Записатися на безкоштовний вебінар: i.goit.global/5tszJ
00:00 Вступ
00:15 Тестування
00:47 TDD Розробка через тестування
04:58 Власний досвід TDD
07:38 Реклама
08:02 Як впровадити TDD
10:23 Проблеми TDD
12:40 Висновок
Станьте спонсором цього каналу, щоб отримувати бонуси:
/ @alex-kovalchuk
Альтернативний спосіб підтримки - www.buymeacoffee.com/alexkova...
Telegram - t.me/AlexKovalchukTg
З питань співпраці і реклами пишіть - t.me/Kelli_Nixe або alex.kovalchuk.media@gmail.com
Записатися на безкоштовний вебінар GoIT Neoversity: i.goit.global/5tszJ
Тести до написання коду - вірний спосіб стати раком, написати в два рази більше коду, наробити в два рази більше помилок і протрахаттся з кодом в два рази більше. Всі страждання програміста елементарно подвоюються, а продуктивність падає. Також побажаю щастя тим програмістам які схильні до наданалізу свого коду. Коли ви добереться до TDD, то перед вами постане велике питання "а що конкретно з цього всього тестувати?". Заранє попереджую що без валідолу, літра кави і начальства у відпустці вам за це краще не братися.
Тим не менш даний підхід дійсно допомагає зменшити кількість логічних помилок в програмі. Продуктивність мабуть що збільшується лише тоді коли в голові є чітке розуміння специфіки проблеми. Якщо ви пишете якусь власну вундервафлю без чітких специфікацій з нуля - це з великою вірогідністю стане вам поперек горла.
Якщо в ви пишете реалізацію якоїсь відомої технології чи алгоритму, тести стануть вірним помічником щоб цим специфікаціям слідувати.
Простим і доволі успішним прикладом TDD підходу можна назвати, наприклад, бібліотеку ArduinoJSON.
Це ще допоможе не братись за виконання якщо усі завдання не чітко зрозумілі. Але це уже з сторони організації роботи
Це як поганий код важко покривати тестами, так і в погану організацію роботи важко поєднати з TDD
Дякую за цей канал і за це відео. Буду ділитися ним з колегами, які так і не наважилися пробувати TDD. Щодо запуску тестів на зміну файлів, коли на проекті їх дуже багато, можу порадити інструменти, які запускають тільки релевантні тести. Наприклад для JS екосистеми це вміє робити Jest у "watch" режимі.
Класний підхід) писати тести після того, як хтось відтестував код і знайшов баги))
А якщо покривати все тестами, з твого досвіду, тестів стає надто багато)
Виходить писати код через тести це гуд, але тест можна скоротити до умовного "все гуд" (що б воно не значило)
Можливо для людей, що вміють в TDD це все зрозуміло і норм, але інші розробники (як я) переживають, що поки будуть розбиратися з тестуванням - згорять усі строки..
Тести так тести! Нехай буде. Головне щоб тести не стали формою прркрастинації 😂.
Молодець! Хороша і атуальна тема. Дякую за роботу
Дякую, дуже цікаво!
Можливо, корисно ;)
Дуже якісно і чітко! А монтаж топчик! І з сірим екраном як наче за кадром дуже подобається 👍
Прикольно, цікаво, розумно
Надаю перевагу BDD. TDD звичайно теж здоровий підхід і має свою нішу, але це в основному бекенд або машинний який не використовується людьми. Власне тому що TDD не пишеться від людини а пишеться від системи TDD буде зрозумілим лише професіоналам які з конкретним фреймворком TDD працюють і знають систему на глибокому рівні. Якщо ж є фронтенд тоді ефективніше по BDD писати - BDD тест кейси пишуться від імені людини, описують дії людини і їх навіть дитина зрозуміє і зможе виконати. SpecFlow/Cucumber в парі з Gherkin - дуже потужні.
Хммм цілком згідний. Я просто фронтенд не пишу тому не дивився в цю сторону так активно. Але тепер почну дивитись)
Дякуємо ❤
Супер важлива тема
Дякую за підтримку
Дякую. Цікаво було почути і ваше відношення до TDD.
Нажаль, є певні обмеження для цієї методології, і великі legacy проєкти, що не покриті тестами - це ще не найгірший випадок. Гірше - це драйвери та bare metal код. Коли залізо - це не просто щось, із чим взаємодіє програма, а тупо половина системи. Коли половина логіки в залізі, а половина - в софті. Коли проблеми вилізають не на рівні логіки, а коли один чіп перегрівся і почав тротлити, а інший очікує від нього сталої продуктивності. І коли знаходиться бага, команда дружно радіє, що вона софтварна і не доведеться дизайнити складні workaround-и хардварним багам...
О, а я про такі обмеження навіть не думав. Ніколи не займався комерційною розробкою драйверів чи чіпів (ну один раз в універі був підробіток, але тоді ще не знав TDD)
Чому б в такому випадку не створити моки/стаби фізичних чипів і не використовувати їх підчас тестів? Тобто якщо стаб об'єкт чіпа працює в звичному режимі то все ок, але якщо отримає більше 1000 повідомлень в секунду то перегрівається й переходить в інший режим.
@@victorbrylew1775 Тому що з тієї інформації, що надав виробник чіпа, це зробити просто неможливо. На навіть якби він надав повну схему логіки, симуляція була б вкрай важкою через складність схеми. Бо DSP-шка.
Так, ви праві, це дійсно виклик. Не бачив жодного проєкту щоб вирішував усі ці питання.
Тут можна лише намагатися стабити і мокати поведінку заліза чи драйвера. Тоді можна протестувати Ваш код. Звісно, 100% покриття досягнути, можливо, не вдасться. Але будуть хоч якісь тести.
@@serhiitimokhin9370 Ну в нас замість симуляції автоматизована ферма із реальним залізом. Тож це краще за "будь-які тести". Але "виклику тестів по кнопці save", як в автора відео, вже не буде.
Маю досвід роботи в стартапах і аутсорсі. Ніде не можу уявити цей підхід якісно. Вони або чітких реквайрментів не дають, по яких можна наперед тести написати, або не виділяють достатньо часу на якісну розробку і тести, або часто просять щось швиденько переробити, і при цьому ніхто не враховує час на переробку тесту і кожен раз за них прилітає. З трьох проектів: 2 команди вирішили їх вирізати через пів року розробки, 1 припинити підтримку і якщо вилазять проблеми - вирізати частинками. Мабуть в ентерпрайз, де більше грошей, це працює краще.
Чекаю кожен випуск як серію улюбленого серіалу.🤗 Завжди щось цікавенька та корисне😊
Дякую, дуже надихає фігачити ще відео
Хочу звернути увагу що підхід ідеалізує розробника в плані що ти маєш описати всі юзеркейси і знати їх наперед що передбачає глибоку постійну роботу над проектуванням знаннями в домені а підтримка і розробка великої кількості тестів передбачає паралелення тестів(оскільки тривалість пайплайна буде рости разом з кстю тестів) підтримку ранерів для пайплайн які будуть рости разом з їх кстю
І справді ТДД непоганий підхід для розробки достатньо простих систем інакше підтримка старих і написання нових тестів будуть зїдати всі переваги і ефективніше буде писати юніттести для покриття найважливіших частин коду і достатньо старого доброго мануального тестування
Це все з особистого досвіду
Дякую за Український вміст.
Дякую за контент. Для маленьких проєктів які потім не будуть допилювати тести, як на мене, взагалі марно писати. =)
Ну але якщо проєкт не помре через місяць, то розвиватись він далі буде і тоді тести відіграють свою роль
Дуже дивний підхід
У мене є проекти без тестів. Не можу сказати, що там прямо дуже гівнокод, але знаю, що я сам не буду і нікому не пораджу впроваджувати тдд в цих проектах))) Ідея для мене дуже не нова, але я про неї часто забуваю, а також зустрічаю команди, які про таке не чули)) Дякую за матеріал. Підписався.
От ще трішки і спробую так писати)
4:45 повеселили 😂
Добре, добре. Звучить переконливо, спробую)
чудовий та незвичний для твого каналу формат. вважаю, що такого немає на україномовному ютубі. тому сподіваюся, будеш частіше підіймати подібні теми в такому форматі!
Постараюсь частіше. Це вузькі теми для доволі малої аудиторії, але уже можу дозволити собі час від часу такі відео робити)
Передивився 30+ ваших відео за один підхід, зараз збираюся іти дибати рекомендовані вами книги та починати проходити cs50.
Дякую за вашу працю та ваше натхнення!
Інколи пишу тести перед завданням, переважно коли воно не обʼємне і повністю зрозуміле. В інших випадках після😅
Дякую. Не закріплюй бумласка думку що мануальне тестування це просто поклацати кнопки чи працює, бо це сильно знецінює роботу. Є багато речей, тестування котрих дуже дорого автоматизувати, і мануальний тестувальник закриває ці потреби прям дуже швидко і якісно, при цьому знаючи тз шукає як програмою будуть користуватись саме користувачі.
TDD дуже схоже на підхід до автоматизованого тестування, прям дякую, повертаєш мені віру в себе, бо завжди здається що я якось не так код пишу)
Спеціально обмовився що мануальне тестування для програміста найпростіше. Бо зазвичай програмісти просто проклікують стандартний шлях.
А ось QA це зовсім інша історія. Вони ковиряють так і в таких місцях де ніхто з програмістів і не здогадувався (тому тестами і не покрив)
Добрий вечір)
Дякую, а у вас буде відео із прикладом ? наприклад написати програму книжний магазин( щось де потрібно пару класів і функцій) бо я сиджу і думаю а як тестити наприклад API , HTML запити, там наприклад звязок із якимось терміналом, тощо. Дякую за такі повчальні відео
Коли пишеш TDD то ідея бізнес логіки перетворюється двічи: перший раз з термінів бізнес логіки в терміни тестів і - другий раз - з термінів тестів до термінів коду. А коли ми пишемо одразу код то перетворення лише одне: з бізнес логіки в код. Так от я на практиці побачив що помилок при одному перетворенні відчутно менше ніж при двох. Тому зара я спочатку пишу функціонал і покриваю тестами підчас дебагу: test driven debugging 😎
Має право на життя (навіть абревіатура не помінялась 😅)
Але зазвичай я навпаки стикався з тим що якщо спочатку не писав тести, то коли з замовником проговорював ТЗ щось важливе пропускав і потім коли половину всього уже впихнув, а інша половина не впихається іду уточнювати і деколи переписувати
Зазвичай це відбувається якщо роблю щось у невідомій для себе сфері
Я чесно кажучи так і не дійшов до розуміння як працювати прям на 100% по ТДД. Ось наприклад є система, в неї є компонент, цей компонент приймає данні на вході, щось там з ними робить і потім віддає результат. Треба на вході додати структуру, потім зробити 10 кроків обробки цих даних і результат обробки додати в результат. В процесі треба змінити 10 файлів, додати декілька файлів, щось відрефакторити і тп. Як одразу почати писати тести якщо ти ще не знаєш що саме будешь міняти? Так, можна принайні написати якийсь інтеграційний тест і потім його запускати, але наприклад юніт тести ти перед кодом не напишеш допоки не зрозумієш а які класи взагалі будуть і які в них функції. А якщо треба міняти існуючі? Питання, одні питання!
Це все детально і з різними прикладами описано в книзі "Test Driven Development: By Example"
Мені unit тести навіть легше писати по TDD ніж інтеграційні. Просто описую параметри на вхід, що очікую на виході, а далі ковиряюсь в реалізації поки не буде віддавати те що на виході теста. Скільки файлів це зачепить - тест не цікавить.
Але якщо дуже багато це привід задуматись про архітектуру
@@alex-kovalchuk ну наприклад я вирішив що ось є вже клас який відповідає за агрегацію даних і я в ньому загрегую ще свій шматок. Я йду, пишу юніт тести, пишу свій код щоб вони пройшли, супер тепер все готово. Але потім я дивлюся на більшу картину та розумію що коли викликається цей компонент то ще не всі дані які мені потрібні для агрегації доступні. Тож я переношу свій код і свої тести в інший клас и дивлюся чи воно тепер там де треба. А потім розумію що тут є спільна логіка для існуючої функціональності і моєї, тож я створюю окремий клас, окремий клас для тестів, несу туди все що вже написав, потім переписую всі тести які вже були (і так ще багато разів). Мені набагато простіше написати якийсь варіант реалізації, перевірити що якийсь загальний хепі кейс працює а потім вже покривати тестами та рефакторити.
ну дай же автору побыть инфоцыганом, книга сама себя не продаст)
Коли не розумієш специфіки задачі - тести до написання коду лише шкодять. Тут все просто. Немає конкретики - немає конкретних вимог до тестів. Відсутність конкретики це головна біль. Не варто подвоювати її наявністю тестів.
Опишіть програму по ходу діла. Таким чином ви краще зрозумієте всі нюанси та перепони на шляху, як і критерії для тестування.
Без прикладів коду з розбиттям на ці задачі оце все виглядає як дешеві балачки які є в перших главах книг про вакуумних конів) вибачте але десь так сприймається рівень такого контенту
Власне в книжці Test Driven Development: By Example" розглядається доволі гарний приклад задачі яка постійно обростає новим функціоналом.
Якщо мені робити щось більш практичне, то це має бути мінімум годинний відос. Де я беру сферу в якій не розбираюсь і пишу по ній pet-проєкт. Бо без цього приклади будуть здаватись занадто ідеально підібрані. Треба, щоб я багато тупив, гуглив і переходив на менші кроки.
Це можна якось зробити, але точно не повноцінним відео, можливо як стрім (але я ніколи ще не стрімив)
@@alex-kovalchukце треба ще вміти так відповісти на такий комент👍👍👍
@@alex-kovalchuk ну все, тепер ми хочемо стрім!
Ну це буде чудове відео. Але мені і теперішній формат подобається. Він зручний тим, що його можна не дивитись, а просто слухати. Для мене це важливо, бо можна під час прогулянок отримувати інформацію про програмування
nice
Методологія не підходить коли необхідно писати код швидко.
Також постійно питання як багато тестів треба зробити? Юніт чи інтонаційний? А якщо завязка на 3д паті?
Якщо є багато часу, то тоді можна займатися цією дичиною ) гарні знання специфікації js і функціональна парадигма куди краще і ефективніше на практиці )
Привіт як гадаєш чи варто використовувати orchid в laravel для створення адмінки?
Ніхто не може заборонити. Але я не використовував (зазвичай просто nova беру, або уже кастомні від замовника)
Сейчас занимаюсь по книге Пайтон Разработка на основе тестирования, так что я просто не мог пройти мимо этого видео 😅. А ведь я даже не джун. Полтора года Пайтон изучаю. Работу найти нереально.
про tdd всі говорять, але хотілось би побачити вживу як писати тести припустимо на laravel. Хоча б кілька прикладів чи тестувтаи контролери чи сервіси ітд ітп
О класс. А як писати функцію реєстрації юзера через тести? Я маю на увазі, на що тоді писати тест, на звпис юзера в дб?І чи взагалі є сенс тестити її, якщо проект на джанґо.
TDD це добре, але що робити коли менеджмент не дає часу такий флоу? бо робота через TDD це x2 а інколи і x3 по часу.
На диво я не так рідко бачу вакансії де вимагають знання тдд
із відеоряду "зашліфовуємо" орнув вголос)
Дядечко Боб, це ти?) дійсно цікава тема і хочеться вивчити її глибше, але з розміткою це поки що не працює 😅
Так, з розміткою в мене також не склалось. Навіть якщо писав якісь e2e тести вони виявлялись занадто крихкими і тому перестав цю справу продовжувати
Працював у великому проекті бачив коли тести реально рятували ситуацію, бачив код який рефакторити для тестів занадто дорого. Основна проблема, як на мене, це те що написання не всього коду прискорюється. Наприклад коли ви робите щось візуальне для клієнта, ви витратите багато часу не на організацію данних. А на візуальні баги. Як що мова не про простий сайт, а наприклад про гру. Усе може бути дуже погано з тестами.
Ага, я помітив сфера game dev дуже сильно відрізняється і по вимогах до коду і до тестів від звичайного програмування комерційних систем.
як порада якщо код не покритий тестами то краще почати з e2e тестами. вони можуть бути написані для всього що зараз використову юзер
і це не смоукінг тест це створення регресивних тестів. смоук тести це просто хепі пас у юзер флоу
100%. Це дозволить побачити що система в цілому працює, бо часто в проекти без тестів і не получається всунути тести без серйозних переписувань (через те що стара реалізація занадто зв'язана і тому погано тестується)
Звучить все дуже класно, але нюансів дуже багато, тому тяжко імплементувати тай взагалі знайти проекти де вже імплементовано tdd, їх не так багато. Як концепт топ, але тут дуже багато але(
На фрілансі мені було дуже важко знайти проекти в яких взагалі тести були не те що TDD
Внатурі, треба підтягнуть.
Звучить гарно, але є але. Де взяти час для написання коду щоб писати код? Я це бачу тільки в розрізі можливо двох програмістів і то з натяжкою. Як покзує особисто мій досвід у бізнесу немає часу на це, продукт потрібен на вчора бо завтра вже буде гівно код від конкурентів але вже буде продукт. Звідки і беруться всілякі фрейворки і т. д.
Азах, файний жарт. Тести для слабаків
1:00 звучить, як маєш таску, перетворюєш в фізичну таску, а потім її виконуєш 😂
Я уже навіть забув що таке фізична таска 😅
У Вас багато відеоставок з захишеним авторським правом(наприклад Сімпстони), нажаль це може бути причиною скарг володаря прав, так можуть попросити ролик видалити, краще більше авторського відео
Там усе по таймінгах вивірено і ютубом перевірено. Попадає під "добропорядне використання"
@@alex-kovalchuk це зрозуміло, але ютуб ютубом, правоволодар може вирішувати самостійно, краще вже куплені на стоках відеовставки
дуже круте відео
я думав шо тдд це хрінь
я розпиши тоді ще топ 10-20 що треба знати і робити джуну щоб стати мідлом....хочаб у відповіді на цей комент
Ну залежить від спеціалізації, але одна з ще ключових штук це DDD (Предметно-орієнтоване проєктування), патерни проектування і вміння спілкуватись (часто дуже недооцінене)
дякую
Отакої, тепер я зрозумів чому звертаючись в лікарню до мануальника, - дивний результат. Вони айтішники?🤔
А як же те що давно вже все до тебе придумали і краще використати якусь готову архітектуру, а вже потім навалити на це все тести і тдд ? А то виходить якась розробка через костилі) ну чи це канає на початку стартапу якогось
Ну це ідея яка просто, на перший погляд, звучить дивно, але гарно працює.
Аналогічно як Tailwind. Я коли вперше стикнувся з ним думав такий: "Ви взагалі на приколі? Може ще просто інлайн стилі мені писати?" а тепер це основний фреймворк для верстки
а без ооп ніззя?
Гоуайті, серйозно?😂
Так, вони з Woolf University зробили доволі круту штуку - онлайн універ з дипломом міжнародного зразка.
І взагалі як компанія вони мені подобаються. Перед курсами дають безкоштовні пробні уроки або мінікурси, щоб людина могла оцінити чи підходить їй такий формат. Є дуже сильні курси, є слабкі, але завжди маєш змогу подивитись що чекає і вирішити чи брати повний курс
@@alex-kovalchuk рівень навчання змінився? Бо це було здирництво грошей за воду, розтягнуту в часі
@@SashaLucasKosh який рівень навчання може бути? Якщо на любих онлайн курсах треба самому пахати? Вони тобі дають тільки матеріал, а ти його береш і вчиш, здаєш домашки і так далі. Тут немає індивідуального підходу, Go It це великий конвеєр з випуску умовно кажучи пиріжків, там ніхто за тобою бігати і просити вчитися не буде. На мою думку таким чином можна вивчитися і самому якщо захотіти,просто там відразу тобі надають потрібний матеріал. Курси на мою думку потрібні якщо вони реально тобі якимось чином допоможуть знайти роботу,тим більше зараз.
Ох, так гарно все почалося, а потім смокінг тести раптом, а звідти вже крок до відмови від тестування загалом. Ну який сенс покривати тестом конкретний баг? Щоб було?
Щоб запевнитись що цей баг не повториться. Якщо смокінг тест писати перед, то це майже оригінальний TDD, особливо у випадку якщо ти гарно розумієш специфіку задачі.
В своєму продукті я використовую смокінг тести (і то їх уже більше 5к) а ось у фріланс чи нових проектах уже використовую повноцінний TDD.
гетманцев який під час війни душить бізнес ні разу не агент ФСБ))
Я звичайно не люблю Гетьманцева і часто про це говорю, але невже я його і в відео про TDD згадував? 😅
@@alex-kovalchuk то мабуть в фоні я слухав відео про Дію, потім перемкнулося на це відео, але ваша згадка про цього чорта тригернула і випадково написав коментар сюди)