Unit тести - стаття блог михаила флёнова

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

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

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

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

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

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

Що трестованої? Бажано трестованої все. Звичайно, за допомогою тестів можна трестованої тільки backend, інтерфейси тут протестувати проблематично, тому ніколи, ні, я б навіть сказав НІКОЛИ, код логіки не повинен бути змішаний з поданням. Це проблема більшості дельфістов і драгенддроперов, які створюють обробник події, і тут же пишуть тупо код. Якщо ви це робите, позбавляйтеся від цієї звички.

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

У мене в команді можна написати будь-яку фігню, але не можна змішувати код і бажано не робити помилок безпеки. Наступними за цими двома речами я намагаюся стежити і саме за цим я роблю code review всього, що летить в git.

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

Так, я пишу юніт тести для себе не для того, щоб вони завершилися успішно, а для того, щоб протестувати свій код. Я взагалі дуже розсіяний, постійно роблю дрібні помилки типу зайвого нулика поставлю (100 замість 10) або можу поставити 1 замість 0, тому що пишу код досить швидко і мене постійно смикають менеджери проекту, а коли тебе відволікають, писати нормально не виходить, просто не можу бути зосередженим. Тому я ставлюся до тестування серйозно. Адже чим краще я зможу перевірити свій код за допомогою тестів, то якісніший продукт я зможу надати клієнту.

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

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

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

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