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

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

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

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

Чи є якась цінність у цьому?

Враховуйте також, що визначення методу може бути розпливчастим, і мені може знадобитися дослідити, що деякі із методів насправді слід робити в певних умовах.

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

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

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

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

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

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

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

 > Is there any value in writing unit tests for code that 
 > already works when inheriting applications?

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

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

ТАК з точки зору якості та розробника, важливо мати Тести.

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

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

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

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

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

Отже, запишіть усі можливі одиничні тести. Що стосується коду, який неможливо перевірити, перефактуруйте свій код на окремі залежності, ввівши «шви» в код - місця, де ви можете відокремити код, який ви хочете перевірити, від коду, який ви не хочете перевіряти.

Ідеї ​​одиничних тестів як характеристичних тестів та швів є головними моментами в роботі «Ефективна робота зі спадковим кодексом » Майкла Пера, книзі, яку я дуже рекомендую.

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

Ви чітко зазначаєте:

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

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

коли я маю час?

У вас є час, коли він стає пріоритетним, правда? Так, це ніколи не відбудеться. :)

Ви намагаєтесь використовувати аспекти тієї бази даних коду, які раніше не використовувались у виробничому додатку? Спочатку напишіть одиничні тести для цих сценаріїв. Вам потрібно мати змогу визначити пріоритетну роботу тут, і я думаю, що Art of Unit Testing мав поради щодо цього (зокрема, як підійти до тестування застарілих баз коду).

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

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

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

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

Удачі!