Наскільки великий мій проект повинен бути для мене, щоб перевірити його? [зачинено]

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

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

Ваш проект вже досить великий.

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

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }

Я ніколи не купував ідею "ти повинен випробувати все", хоча там, звичайно, є люди (див . Відповідь гната !).

Що стосується мене, головними перевагами одиничного тестування є:

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

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

Число 1, як правило, достатньо, щоб зробити його варто написанням тестів. На мій досвід,> 95% коду рано чи пізно змінюється.

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

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

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

Деякий час тому я знайшов приємний пост: Чому тестування приладів прискорює розвиток . Це може допомогти вам відповісти на питання.

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

У мене є «віра».

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

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

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

Майкл Перо представив в одній зі своїх книг два способи роботи зі змінами коду:

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

Не має значення, наскільки велика база коду.

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

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

Тестові модулі реалізовані для економії часу та вдосконалення:

• відстеження помилок
• рефакторинг та / або перезапис коду
• інтеграційне тестування
• регресійне тестування тощо.

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

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

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

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

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

Різниця між тестуванням одиничних тестів та відсутністю їх є різницею між витратами на написання тесту та вартістю його виконання порівняно з витратами на тестування вручну.

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

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

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

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

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

Версія TL; DR :

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

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

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

Пригнічіть цей страх, нехай він виросте до адекватних розмірів: чим раніше ви протестуєте, тим краще.

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

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

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

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

Цитата з "Чистого коду" Роберта К. Мартіна : "Якщо писати тривіально, тестувати банально", тож немає приводу пропускати тестування для коротких і тривіальних програм.

Це насправді не питання розміру - це те, що ви робите з ним (і скільки років). Якщо я обміюсь вивченням того, як працює технологія, і планую відкинути річ (у Scrum ми це називаємо шипом), я просто зашифрую, не роблячи тестування. Якщо ви плануєте розвивати його далі (навіть якщо ви просто лапшаєте навколо), вам слід написати тести навколо коду. TDD - це технологія проектування, ще до того, як це метод тестування. Ви хочете мати чітке уявлення про те, що ви хочете зробити, перш ніж зав'язатись у деталях виконання. Я б також НЕрекомендуємо спробувати написати великі одиничні тести навколо великої кількості застарілого коду. Спробуйте визначити ті складні частини (які мають високу циклічну складність / код спагетті до них) та ті частини, які часто виходять з ладу (вони часто будуть однаковими). Як підказали інші, я б хотів прочитати книгу Кента Бека на TDD і, безумовно, прочитав книгу Майкла Пера. Те, що вони не дуже охоплюють, - це політичний аспект написання одиничних тестів навколо коду. Дуже багато розробників ненавидять змінювати свій код, щоб зробити його тестируемим, а багато розробників взагалі не відчувають необхідності тестувати код. Це те, над чим ми маємо працювати, як професія. Кожна інша інженерна дисципліна зобов'язана довести (часто математично), що їх робота відповідає специфікації. Ми повинні зробити те саме.

Зв'язування проектів у межах класів або функціональності, а потім судження, чи підходить це тестування для одиниць, може бути помилковим. Існує чимало переваг тестування програми, але справжня краса починається тоді, коли вам доведеться підтримувати додаток або працювати в розподіленому середовищі. Тож вибір приходить сюди. Навіть невелика зміна коду може спричинити катастрофи.
Я б не лише запропонував «Тестування одиниць», але також рекомендував би перевірити покриття коду, гарантуючи, що максимум вашого коду покрито Тестовим модулем. Поріг покриття коду не повинен бути менше 95%, а цільовий показник повинен становити близько 100% . Ви можете скористатися інструментами для відстеження покриття коду та створення звіту.
Visual Studio надає дані покриття -http://msdn.microsoft.com/en-us/library/ms182496(v=vs.80).aspx
Також можна використовувати NCover або dotCover.