Пиши тести ПЕРЕД кодом! TDD - розробка через тестування 

Записатися на безкоштовний вебінар GoIT Neoversity: i.goit.global/5tszJ

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

Дякую за цей канал і за це відео. Буду ділитися ним з колегами, які так і не наважилися пробувати TDD. Щодо запуску тестів на зміну файлів, коли на проекті їх дуже багато, можу порадити інструменти, які запускають тільки релевантні тести. Наприклад для JS екосистеми це вміє робити Jest у "watch" режимі.

Класний підхід) писати тести після того, як хтось відтестував код і знайшов баги)) А якщо покривати все тестами, з твого досвіду, тестів стає надто багато) Виходить писати код через тести це гуд, але тест можна скоротити до умовного "все гуд" (що б воно не значило) Можливо для людей, що вміють в TDD це все зрозуміло і норм, але інші розробники (як я) переживають, що поки будуть розбиратися з тестуванням - згорять усі строки..

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

Дуже якісно і чітко! А монтаж топчик! І з сірим екраном як наче за кадром дуже подобається 👍

Дякую за контент. Для маленьких проєктів які потім не будуть допилювати тести, як на мене, взагалі марно писати. =)

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

Тести так тести! Нехай буде. Головне щоб тести не стали формою прркрастинації 😂.

У мене є проекти без тестів. Не можу сказати, що там прямо дуже гівнокод, але знаю, що я сам не буду і нікому не пораджу впроваджувати тдд в цих проектах))) Ідея для мене дуже не нова, але я про неї часто забуваю, а також зустрічаю команди, які про таке не чули)) Дякую за матеріал. Підписався.

Хочу звернути увагу що підхід ідеалізує розробника в плані що ти маєш описати всі юзеркейси і знати їх наперед що передбачає глибоку постійну роботу над проектуванням знаннями в домені а підтримка і розробка великої кількості тестів передбачає паралелення тестів(оскільки тривалість пайплайна буде рости разом з кстю тестів) підтримку ранерів для пайплайн які будуть рости разом з їх кстю І справді ТДД непоганий підхід для розробки достатньо простих систем інакше підтримка старих і написання нових тестів будуть зїдати всі переваги і ефективніше буде писати юніттести для покриття найважливіших частин коду і достатньо старого доброго мануального тестування Це все з особистого досвіду

Дякую. Цікаво було почути і ваше відношення до TDD. Нажаль, є певні обмеження для цієї методології, і великі legacy проєкти, що не покриті тестами - це ще не найгірший випадок. Гірше - це драйвери та bare metal код. Коли залізо - це не просто щось, із чим взаємодіє програма, а тупо половина системи. Коли половина логіки в залізі, а половина - в софті. Коли проблеми вилізають не на рівні логіки, а коли один чіп перегрівся і почав тротлити, а інший очікує від нього сталої продуктивності. І коли знаходиться бага, команда дружно радіє, що вона софтварна і не доведеться дизайнити складні workaround-и хардварним багам...

Чекаю кожен випуск як серію улюбленого серіалу.🤗 Завжди щось цікавенька та корисне😊

Інколи пишу тести перед завданням, переважно коли воно не обʼємне і повністю зрозуміле. В інших випадках після😅

Дякую за Український вміст.

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

Я чесно кажучи так і не дійшов до розуміння як працювати прям на 100% по ТДД. Ось наприклад є система, в неї є компонент, цей компонент приймає данні на вході, щось там з ними робить і потім віддає результат. Треба на вході додати структуру, потім зробити 10 кроків обробки цих даних і результат обробки додати в результат. В процесі треба змінити 10 файлів, додати декілька файлів, щось відрефакторити і тп. Як одразу почати писати тести якщо ти ще не знаєш що саме будешь міняти? Так, можна принайні написати якийсь інтеграційний тест і потім його запускати, але наприклад юніт тести ти перед кодом не напишеш допоки не зрозумієш а які класи взагалі будуть і які в них функції. А якщо треба міняти існуючі? Питання, одні питання!

Дуже дивний підхід

Дякую, дуже цікаво! Можливо, корисно ;)

Молодець! Хороша і атуальна тема. Дякую за роботу

Коли пишеш TDD то ідея бізнес логіки перетворюється двічи: перший раз з термінів бізнес логіки в терміни тестів і - другий раз - з термінів тестів до термінів коду. А коли ми пишемо одразу код то перетворення лише одне: з бізнес логіки в код. Так от я на практиці побачив що помилок при одному перетворенні відчутно менше ніж при двох. Тому зара я спочатку пишу функціонал і покриваю тестами підчас дебагу: test driven debugging 😎

Дякуємо ❤ Супер важлива тема

Прикольно, цікаво, розумно

Без прикладів коду з розбиттям на ці задачі оце все виглядає як дешеві балачки які є в перших главах книг про вакуумних конів) вибачте але десь так сприймається рівень такого контенту

Дякую, а у вас буде відео із прикладом ? наприклад написати програму книжний магазин( щось де потрібно пару класів і функцій) бо я сиджу і думаю а як тестити наприклад API , HTML запити, там наприклад звязок із якимось терміналом, тощо. Дякую за такі повчальні відео

Методологія не підходить коли необхідно писати код швидко. Також постійно питання як багато тестів треба зробити? Юніт чи інтонаційний? А якщо завязка на 3д паті?

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

От ще трішки і спробую так писати)

Добре, добре. Звучить переконливо, спробую)

Добрий вечір)

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

4:45 повеселили 😂

TDD це добре, але що робити коли менеджмент не дає часу такий флоу? бо робота через TDD це x2 а інколи і x3 по часу.

про tdd всі говорять, але хотілось би побачити вживу як писати тести припустимо на laravel. Хоча б кілька прикладів чи тестувтаи контролери чи сервіси ітд ітп

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

О класс. А як писати функцію реєстрації юзера через тести? Я маю на увазі, на що тоді писати тест, на звпис юзера в дб?І чи взагалі є сенс тестити її, якщо проект на джанґо.

Привіт як гадаєш чи варто використовувати orchid в laravel для створення адмінки?

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

nice

Дядечко Боб, це ти?) дійсно цікава тема і хочеться вивчити її глибше, але з розміткою це поки що не працює 😅

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

Внатурі, треба підтягнуть.

із відеоряду "зашліфовуємо" орнув вголос)

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

Сейчас занимаюсь по книге Пайтон Разработка на основе тестирования, так что я просто не мог пройти мимо этого видео 😅. А ведь я даже не джун. Полтора года Пайтон изучаю. Работу найти нереально.

Азах, файний жарт. Тести для слабаків

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

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

Отакої, тепер я зрозумів чому звертаючись в лікарню до мануальника, - дивний результат. Вони айтішники?🤔

1:00 звучить, як маєш таску, перетворюєш в фізичну таску, а потім її виконуєш 😂

а без ооп ніззя?

У Вас багато відеоставок з захишеним авторським правом(наприклад Сімпстони), нажаль це може бути причиною скарг володаря прав, так можуть попросити ролик видалити, краще більше авторського відео

Гоуайті, серйозно?😂

Ох, так гарно все почалося, а потім смокінг тести раптом, а звідти вже крок до відмови від тестування загалом. Ну який сенс покривати тестом конкретний баг? Щоб було?

гетманцев який під час війни душить бізнес ні разу не агент ФСБ))