Чи використовуєте ви одиничні тести на роботі? Які вигоди ви отримуєте від них? [зачинено]

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

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

деякі з них підказують мені, що це не потрібно

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

і це має дуже мало користі.

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

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

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

ви застосовували одиничний тест на своїй роботі і що ви отримуєте від нього? (наприклад, краща якість коду, скорочення часу в довгостроковій перспективі тощо)

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

Я роблю одиничні тести, але не (або декілька) на роботі

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

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

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

Коли вся команда погоджується (а в команді 1, що легко), на мій досвід, тести є великою користю для якості, стилю та надійності Проекту.

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

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

Я схильний сторони з вашими колегами, але лише до певного моменту.

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

def add(x, y)
  x + y
end

Поряд з десяткам тестів, щоб переконатися, що додаток дійсно працює для довільно обраних випадків використання. Да ...

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

1. Коли ви тестуєте
2. Коли ви налагоджуєте
3. Як ви розробляєте справді хитрі речі

Давайте розглянемо кожен з них, припустимо, що ви розробляєте якийсь веб-додаток для веб-сайту.

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

Потім ви виявите помилку (яка ніколи не пропускає жодної?). Це підводить нас до пункту два. Ви повертаєтесь у код і починаєте виконувати кроки. Як ви робите, пишіть одиничні тести у ключових точках перерви, коли важливість послідовних та правильних даних є визначальною.

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

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

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

Весь код повинен бути протестований. Вибору з цього приводу немає.

Неперевірений код марний: йому не можна довіряти нічого робити.

Ви можете писати одиничні тести або сподіватися написати тести інтеграції вищого рівня або тести прийняття.

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

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

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

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

Це робить модульне тестування логічною необхідністю. Іншого вибору немає.

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

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

Це дає мені:

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

Одиничне тестування - це дисципліна. Оскільки код не працює, він часто відкидається.

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

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

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

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

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

C ++, багатопотокова конструкція та GUI стануть кошмаром, і покриття проблеми буде жахливим.

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

Чи варто того, я не можу реально сказати.

Чи багато у вас рефактор? Чи багато ви бачите у своєму коді "дурні помилки" на кшталт "від одного"?

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

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

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

Ми їх використовуємо. Одним з великих переваг, які ми отримуємо, є перевірка рамкових тестів на предмет витоків пам’яті та збоїв у розподілі . Іноді проблема полягає в самому тестовому коді пристрою, але часто він полягає у виробничому коді.

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

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

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

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

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

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

Витрати: повільніше до коду, крива навчання, інерція розробника

Переваги: ​​як правило, я описував кращий код, коли я перевіряв перший - ТВОРИЙ ...

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

Я роблю тестування на роботі, коли отримую можливість, і намагаюся переконати своїх колег зробити те саме.

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

Там, де я побачив реальну перевагу кодування Unit Tests та зробити виконання тестових одиниць частиною щоденного процесу збирання, був проект, в якому працювали 30+ розробників, які працюють на 3 різних континентах. Там, де дійсно просвічували одиничні тести, коли хтось тонко змінив клас, який вони підтримували, не розуміючи, як люди використовують цей клас. Замість того, щоб чекати, коли код потрапить на тестувальну групу, з'явився негайний зворотній зв'язок, коли в результаті зміни люди почали провалюватися. [Ось чому всі одиничні тести потрібно регулярно виконувати, а не лише ті, які ви написали для свого коду.]

Мої вказівки щодо тестування одиниць:

1. Перевірте кожну умову, про яку ви можете придумати свій код, включаючи погані введення, межі тощо.
2. Усі тести одиниць для всіх модулів повинні виконуватися регулярно (тобто як частина нічних збірок)
3. Перевірте результати тестових одиниць!
4. Якщо хтось знайде помилку у вашому коді, який минув ваші тести, напишіть для нього новий тест!

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

Найважче - це написання хороших одиничних тестів.

Це хороший орієнтир для вашого коду.