Чи варто тестування одиниць? [зачинено]


572

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


25
Як ти можеш запитати таке? .. Одиничне тестування таке хіп :)? Серйозно ... загальна ідея та ж ... зробіть тестування, якщо відчуваєте, що користь переважає вартість ... якщо у вас є підстави вірити в інше ... знайдіть щось інше, що допомагає.
Гішу

14
(регулярні твердження з налагодженням \ випуск версії + чистий інтерфейс до класів + виділений фіктивний тестер)> тестування одиниць
Віктор Sehr

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

7
@ViktorSehr: модульні тести не суперечать чистим інтерфейсам, адже вони застосовують TDD. Або це, або водійське сидіння + кермо> гараж.
Jonas Byström

5
Тестування приладів - це велика витрата часу, яка рідко коли-небудь виявляє помилки, але з'їдає 30% часу та бюджету на виправлення помилок та час розробки
Домінік

Відповіді:


722

Щодня в нашому офісі відбувається обмін, який проходить приблизно так:

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

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

Але, ігноруючи це, ось моя спроба!

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

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

  3. Тести та код працюють разом, щоб досягти кращого коду. Ваш код може бути поганим / невдалим. ТЕСТ може бути поганим / баггі. У TDD ви бавитесь на шанси як поганий / баггі низький. Часто це тест, який потребує виправлення, але це все-таки хороший результат.

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

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

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

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

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

  9. Хороші одиничні тести можуть допомогти документувати та визначити, що потрібно робити

  10. Блок тестів допомагає при повторному використанні коду. Перемістіть і свій код, і свої тести на новий проект. Налаштуйте код, доки тести знову не запустяться.

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


Чи є презентація, яку ви посилаєте .xul?
user2427

3
Питання стосувалося одиничного тестування. TDD - це зовсім інша річ, ніж одиничне тестування.
ZunTzu

421

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

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

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

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

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


15
приголомшливий анекдот!
Сандер Верслуйс

68
Ваші ідеї мене інтригують, і я хочу підписатися на вашу розсилку.
Крістофер Паркер

165
Лайно, я вже перевірений, але тепер ти змушуєш мене ходити в спортзал.
Вінс

16
Мені не подобається. Я зазнаю невдачі як видовище і як людина.
Грег

13
+1: Багато менеджерів заспівають похвали Unit Unit Testing, але це не означає, що вони будуть дотримуватися цього, коли це важливо ... Можливо, вам знадобиться знайти нову роботу, щоб дійсно зробити тестування для вас. - Чудові бали. Дуже правильно.
Джим Г.

136

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

Ця конкретна помилка навряд чи з’явиться знову, і ви можете довести це своїм тестом.

Якщо ви цього зробите достатньо, інші швидко дотягнуться.


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

7
@Rei - звіт про помилку, що підтверджується, чудовий, але ви лише збираєтесь відтворити помилку ОК. Через 2 роки ваш блок перевірки все ще буде перевіряти код, довго після закриття та забуття звіту про помилку.
Оріон Едвардс

4
Це економить помилку виправлення 1 ... тест ... добре. Користувачі знаходять помилку 2 ... виправити ... тестувати ... добре. Користувачі знову знайдуть помилку 1. Натріть, промийте, повторіть. Це відбувається тому, що ваше виправлення однієї помилки, викликає інше, і навпаки.
CaffGeek

1
@Rei Miyasaka: "Можливо, якщо у вас є кілька людей, які підтримують проект", - я б сказав, що це майже всі нетривіальні проекти. Щодо "просто залиште коментар": Проблема полягає в тому, що можуть (тобто будуть ) взаємодії з іншим кодом, що може спричинити появу помилки. Ось чому ви насправді повинні пройти тест.
sleske

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

69

thetalkingwalnut запитує:

Які є хороші способи переконати скептично налаштованих розробників у цінності Unit Testing?

Усі тут збираються з безлічі причин, чому невідомо тестування. Однак я вважаю, що часто найкращий спосіб переконати когось у чомусь - вислухати їхній аргумент та звертатися до нього по пункту. Якщо ви слухаєте і допомагаєте їм висловити свої занепокоєння, ви можете звернутися до кожного з них і, можливо, перетворити їх на вашу точку зору (або, принаймні, залишити їх без ноги, щоб вони стояли). Хто знає? Можливо, вони переконають вас, чому одиничні тести не підходять для вашої ситуації. Не ймовірно, але можливо. Можливо, якщо ви опублікуєте їх аргументи проти одиничних тестів, ми можемо допомогти визначити контраргументи.

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

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

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

    • Якщо розробник стверджує, що метод здається занадто простим, щоб його не вдалося, чи не варто брати 60 секунд, необхідних для написання простого тесту на 5-рядковий блок? Ці 5 рядків коду працюватимуть щовечора (ви займаєтеся нічними побудовами, правда?) Протягом наступного року і більше, і варто буде докласти зусиль, якщо навіть раз, коли це трапиться, виникла проблема, яка може зайняти 15 хвилин або довше, щоб виявити і налагодження. Крім того, написання простих одиничних тестів збільшує кількість одиниць тестів, завдяки чому розробник виглядає добре.

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

  2. Розробнику потрібно намалювати «лінію в піску», наскільки комплексними повинні бути їх одиничні тести. Пізніше в розробці, коли ми знайдемо помилку, вони повинні визначити, чи могли б виявити більш комплексні тести одиниць. Якщо так, і якщо такі помилки з'являються неодноразово, їм потрібно перенести "рядок" на написання більш всеосяжних тестів на одиницю в майбутньому (починаючи з додавання або розширення одиничного тесту для поточної помилки). Їм потрібно знайти правильний баланс.

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

Однак нам потрібно зрозуміти вплив "більше одиничних тестів". Розробник може писати лише ~ N рядків коду на тиждень, і вам потрібно розібратися, який відсоток цього коду має бути одиничним тестовим кодом та виробничим кодом. Легке робоче місце може мати 10% коду як одиничне тестування і 90% коду як виробничий код, в результаті чого продукт має безліч (хоча і дуже баггі) функцій (думаю, MS Word). З іншого боку, у суворому цеху з 90% тестовими одиницями та 10% виробничим кодом буде надійний продукт з дуже мало функцій (подумайте "vi"). Ви ніколи не чуєте повідомлень про збій останнього продукту, але це, ймовірно, має стільки ж спільного з тим, що товар не продається дуже добре, як це стосується якості коду.

Що ще гірше, мабуть, єдина впевненість у розробці програмного забезпечення полягає в тому, що "зміни неминучі". Припустимо, суворий цех (90% одиниць тестів / 10% виробничого коду) створює продукт, який має рівно 2 функції (якщо припустити 5% виробничого коду == 1 особливість). Якщо замовник приходить і змінює 1 функцію, то це міняє сміття 50% коду (45% одиничних тестів і 5% виробничого коду). Магазин розрядки (10% одиниць тестів / 90% виробничий код) має товар з 18 особливостями, жодна з яких не працює дуже добре. Їх клієнт повністю переосмислює вимоги до 4-х своїх особливостей. Навіть незважаючи на те, що зміна в 4 рази більша, лише половина більшої частини коду потрапляє під удар (~ 25% = ~ 4,4% одиничних тестів + ​​20% виробничого коду).

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


47
Якщо у Vi дуже мало функцій, ви її не використовуєте. ;)
Стефан Май

1
+20 для Стефана, якщо б міг :)
Роб Грант

1
Testivus на тестовому покритті - googletesting.blogspot.com/2010/07/…
Bert F

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

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

38

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

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

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

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


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

4
Тестування - це все про щастя. У мене є пакет 3900 рядків (PL / SQL), який обробляє автоматизовані повідомлення в загальній системі ведення книги. Зараз я особисто ненавиджу спілкування з бухгалтерами - вони такі вибагливі до дрібниць, як дрібні копійки та інше. Buncha анально-стримуючі арифметичні вундеркінги ... Я не знаю. Моя одиниця тестового пакету для бухгалтерського пакету становить приблизно 22000 рядків і працює трохи менше 18000 тестів. Це тримає Голову Гончо в бухгалтерському обліку всіх щасливими, і поки пропелер на його маленькій шапці-підрахунку шапочки щасливо крутиться, я щасливий ... :-)
Боб Джарвіс - Відновити Моніку

31

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


26

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

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

Фрагменти коду можуть стати великою допомогою для зменшення витрат на створення тестів. Не важко створити фрагменти, які дозволять створити контур класу та пов’язане з ним тестовий пристрій за секунди.


25

Ви повинні тестувати якомога менше!

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

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


23

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


21

[У мене є пункт зробити, що я не можу бачити вище]

"Всі одиничні тести, вони не обов'язково усвідомлюють це - ФАКТ"

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

Це тестова одиниця - основна і погано складена, але ви перевіряєте фрагмент коду для кількох випадків.

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

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


16

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

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

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

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

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


12

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


11

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

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

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


10

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

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

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

Останньою порадою буде не лише перевірити свій код, але розпочати тест спочатку (детальніше див. TDD та BDD )


8

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


7

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

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

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

Я купив цю книгу - це Біблія xUnit Тестування знань - це, мабуть, одна з найбільш посиланих книг на моїй полиці, і я консультую її щодня: текст посилання


+1 . - Такий справжній. Мені б хотілося, щоб я це раніше зрозумів.
Джим Г.

7

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

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


+1: Взяття невеликої кількості часу для написання одиничного тесту може заощадити години майбутньої налагодження. - Так!
Джим Г.

7

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

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


Ви додаєте одиничні тести для нового коду чи виправлень, які ви робите?
квітня 1515

6

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

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

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


6

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


6

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


Зауважте, це було майже 15 років тому, коли тестування приладів було не таким популярним, як сьогодні.
fwielstra

1
І Internet Explorer все ще не вдається зберегти багато веб-сторінок.
Cees Timmerman

5

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

Замість того, щоб говорити про тестування одиниць з точки зору перевірки "test-after", ми повинні переглянути справжнє значення, знайдене, коли ви поставилися перед написанням специфікації / тесту / ідеї.

Ця проста ідея змінила спосіб написання програмного забезпечення, і я не повернувся би до "старого".

Як перший тест змінив моє життя


1
+1 - і я мушу сказати, що це дивовижно, скільки тролів залучає запис до блогу (до того, як ви розміщуєте тут, якщо я не помиляюся).
Jeff Sternal

ха-ха погодився :) </ reddit передня сторінка робить так, як здається>
Торан Біллапс

3

Так - Тестування одиниць, безумовно, варто докласти зусиль, але ви повинні знати, що це не срібна куля. Тестування блоку - це робота, і вам доведеться працювати над тим, щоб тест оновлювався та був актуальним у міру зміни коду, але пропоноване значення вартує зусиль, які вам доведеться вкласти. Можливість безперешкодно перефактурувати - величезна користь, оскільки ви завжди можете перевірити функціональність запустивши тести після будь-якого коду зміни. Хитрість полягає в тому, щоб не надто зависати саме на тестувальну одиницю роботи або про те, як ви виконуєте вимоги для тестування лісів, і коли тест дійсно є функціональним тестом тощо. Люди будуть годинами сперечатися з цього приводу зрештою, і реальність полягає в тому, що будь-яке тестування, яке ви робите як код запису, краще, ніж не робити цього. Інша аксіома стосується якості, а не кількості - я бачив кодові бази з 1000 ' s тесту, які по суті є безглуздими, оскільки решта насправді не перевіряють нічого корисного або будь-якого конкретного домену, як бізнес-правила тощо для конкретного домену. Я також бачив кодові бази з 30% покриттям коду, але тести були релевантними, значущими та справді приголомшливими, оскільки вони перевіряли основні функціональні можливості коду, для якого він був написаний, і висловлювали, як слід використовувати код.

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


3

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

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

і великий ...

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

+1: • Можливо, вам не знадобиться тестування одиниць, але коли хтось інший заходить і змінює код без повного розуміння, він може наздогнати багато дурних помилок, які вони можуть зробити. - Так. А враховуючи обсяг обороту в індустрії програмного забезпечення, це величезна вигода.
Джим Г.

3

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

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

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


3

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

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

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


2

Якщо ви використовуєте NUnit, одна проста, але ефективна демонстрація - запустити перед ними власний тестовий набір NUnit. Побачивши справжній тестовий набір, який дає тренування кодовій базі, варто тисячу слів ...


2

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


2

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


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.