Коли доцільно не проводити одиничний тест?

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

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

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

Тож я щоразу закінчую тим самим висновком. Рентабельність інвестицій занадто низька.

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

У моїй ситуації, ви все-таки знайдете спосіб зробити тестування підрозділу звичайною практикою, або я обґрунтовано уникаю цих витрат?

ОНОВЛЕННЯ: Кілька речей щодо моєї ситуації, яку я пропустив: Мої проекти - це всі веб-програми. Щоб покрити весь мій код, мені доведеться використовувати автоматизовані тести інтерфейсу користувача, і це область, де я досі не бачу великої користі від ручного тестування.

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

Тому? Вам не доведеться все тестувати . Просто відповідні речі.

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

Це насправді помилково. Це не більш ефективно. Це насправді просто звичка.

Інші розробники соло - це зробити ескіз чи контур, написати тестові випадки та потім заповнити контур кінцевим кодом.

Це дуже, дуже ефективно.

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

Це теж помилково. Тести не є тягарем. Зміни вимог - це перетягування.

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

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

Ви можете мати обмежений тест прийняття "ось це".

Або ви можете провести одиничні тести.

Або ви можете мати і те, і інше.

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

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

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

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

Так, ви могли б зробити все це! А що буде з вашим кодом з часом? Він стане чистішим та чистішим, оскільки не буде ризику його очищення.

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

Скільки налагодження, на вашу думку, ви зробили б?

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

Скажімо, ви повертаєтесь до системи, яку ви побудували рік тому, і ви забули, як створити один з центральних об’єктів. Існують тести, які створюють цей об'єкт усіляко, як він може бути створений. Ви можете прочитати ці тести і пробіг свою пам'ять. Вам потрібно зателефонувати в API? Існують тести, які викликають цей API всі способи його виклику. Ці тести - це невеликі документи , написані зрозумілою мовою. Вони абсолютно однозначні. Вони настільки формальні, що страчують. І вони не можуть вийти з синхронізації з додатком!

Не варто інвестувати? Ти мусиш жартувати мене! Як хтось НЕ захотів цього тесту? Зробіть собі прихильність і перестаньте хизуватися через дурість. Навчіться робити TDD добре і дивіться, наскільки швидше ви їдете та наскільки чистіший ваш код.

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

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

По-друге, їх виявлення виявляє помилки, які в іншому випадку з’являться при тестуванні.

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

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

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

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

Хлопці в JUnit (тестова рамка Java Unit) мають філософію, що якщо це занадто просто для тестування, не тестуйте її . Я настійно рекомендую ознайомитись із їхніми питаннями про найкращі практики , оскільки це досить прагматично.

TDD - це інший процес написання вашого програмного забезпечення. Основна передумова тестування одиниці полягає в тому, що ви витратите менше часу на відладчик, перебираючи код, і швидше з'ясуйте, чи змінить ваш код випадково зламає щось інше в системі. Це вписується в TDD. Цикл TDD виглядає так:

1. Напишіть тест
2. Слідкуйте за тим, щоб не вдалося (доведіть, що вам щось потрібно)
3. Напишіть лише те, що потрібно для проходження тестового проходу - не більше.
4. Дивись, як це проходить (так!)
5. Рефактор (покращити його)
6. Вимийте, промийте та повторіть

Що менш очевидно у застосуванні TDD, це те, що він змінює спосіб написання коду . Змушуючи себе думати про те, як перевірити / перевірити, чи працює код, ви пишете тестовий код. А оскільки ми говоримо про тестування модулів, це означає, що ваш код стає більш модульним. Для мене модульний і тестуваний код - це велика перемога.

Тепер вам потрібно перевірити такі речі, як C # властивості? Уявіть собі властивість, визначену так:

bool IsWorthTesting {get; set;}

Відповідь була б "ні", це не варто тестувати, тому що в цей момент ви тестуєте мовну особливість. Тільки довіртесь, що хлопці з платформи C # правильно зрозуміли. Крім того, якщо це не вдалося, що ви могли б зробити, щоб виправити це?

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

• Перевірили винятки, які можуть статися лише в тому випадку, коли встановлення пішло погано. У Java є багато таких. Вам потрібно написати блок спіймання або оголосити перевірений виняток, навіть якщо немає способу його не вдатися без злому встановлених файлів.
• Інтерфейси користувача. Пошук тестового контролю та виклик правильних подій для імітації дій користувача дуже клопітно, а в деяких випадках неможливо. Однак якщо ви використовуєте модель Model / View / Controller, ви можете переконатися, що ваша модель та контролери перевірені та залишити перегляд деталі вручну.
• Взаємодія клієнт / сервер. Це вже не одиничний тест, а тепер інтеграційний тест. Напишіть усі частини, які надходять до надсилання та отримання повідомлень по дроту, але насправді не переходьте по дроту. Хороший підхід полягає у зменшенні відповідальності коду, який насправді передає провід до необмежених комунікацій. У вашому тестовому коді одиниці вимкніть об’єкт зв’язку, щоб переконатися, що служби ведуть себе так, як ви очікували.

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

Ви повинні збалансувати вартість тестування з вадами помилок.

Писати тест на 10 рядків для функції, яка відкриває файл, де збій "файл не знайдено" є безглуздим.

Функція, яка робить щось складне до складної структури даних - тоді, очевидно, так.

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

Тестування - азартні ігри.

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

Як і будь-яка ставка, іноді ви виграєте, іноді програєте.

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

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

Моя порада - лише перевірити код, який ви хочете працювати належним чином.

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

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

Тестування TDD та Unit - це не одне і те ж.

Ви можете написати код, а потім додати одиничні тести пізніше. Це не TDD, і це багато зайвої роботи.

TDD - практика кодування в циклі Червоного світла. Зелене світло. Ітерації рефактора.

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

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

Я працював над системою, де ми протестували майже все. Помітними виконанням для тестування були вихідний код PDF та XLS.

Чому? Нам вдалося протестувати частини, які збирали дані, і побудували модель, яка використовувалася для створення результату. Нам також вдалося протестувати частини, які з'ясували, які частини моделі перейдуть до PDF-файлів. Ми не змогли перевірити, чи PDF виглядав нормально, оскільки це було абсолютно суб'єктивно. Ми не змогли перевірити, чи всі частини PDF-файлу читалися типовому користувачеві, оскільки це було також суб'єктивно. Або якщо вибір між діаграмами та круговими діаграмами був правильним для набору даних.

Якщо результат буде суб'єктивним, мало одиничних тестувань, ви можете зробити те, що варто зусиль.

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

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

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

TL; DR Це дійсно ніколи не підходить, оскільки переваги просто надто хороші.

Два дуже хороших відповіді, які я натрапив, є тут:

1. Коли проводити тестовий модуль проти тестування вручну
2. Що не тестувати, коли мова йде про тестування одиниць?

Обгрунтування уникнення сприйнятого накладних витрат:

• Негайне економія часу / витрат для вашої компанії
• Потенційний час / економія витрат на усунення несправностей / ремонту / розширення в довгостроковій перспективі навіть після того, як ви не підете.

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

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

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

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

Я б не повертався назад і писав цілу партію тестів для коду, який ви вже відправили, але наступного разу, коли вам потрібно змінити функцію, я б запропонував спробувати написати тести для цього модуля або класу, отримайте покриття до 70% + перед тим, як застосувати будь-які зміни. Подивіться, чи допоможе вам це.

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

Здається, що більшість відповідей є про-TDD, навіть якщо питання стосувалося не TDD, а загальних тестів.

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

1. Приватні методи

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

2. Речі, які ви вже знаєте, повинні працювати (або речі, перевірені кимось іншим)

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

І те і інше можна застосувати, чи ви робите TDD, чи ні.

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

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

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

public interface ITest {
    public string Name {
        get;
    }
    public string Description {
        get;
    }
    public List<ITest> SubTests {
        get;
    }
    public TestResult Execute();
}

public class TestResult {
    public bool Succesful {
        get;
        set;
    }

    public string ResultMessage {
        get;
        set;
    }

    private Dictionary<ITest, TestResult> subTestResults = new Dictionary<ITest, TestResult>();
    public Dictionary<ITest, TestResult> SubTestResults {
        get {
            return subTestResults;
        }
        set {
            subTestResults = value;
        }
    }
}

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

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

Удачі!