Я щойно закінчив ступінь CS, і в даний час я працюю молодшим розробником .NET (C #, ASP.NET та веб-форми). Ще коли я навчався в університеті, предмет блочного тестування не висвітлювався, але я ніколи не бачив його переваг. Я розумію, що він повинен робити, а саме визначити, чи підходить блок коду для використання. Однак мені ніколи раніше не доводилося писати одиничний тест, і я ніколи не відчував потреби в цьому.

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

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

Отже, питання № 1: Чи формує тестові одиниці для веб-сайтів ASP.NET те, що робиться часто, і якщо це так: як вирішити проблему "динамічного середовища"?

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

Отже, питання № 2: Ви б порадили мені почати писати одиничні тести? Я думаю, що це може допомогти мені в реальній реалізації, але потім знову відчуваю, що це може сповільнити мене.

На мою думку: так вони є, і так, слід.

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

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

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

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

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

Я б порадив вам попрактикуватись і парувати програму. Під час читання:

• Agile Розробка програмного забезпечення, принципи, шаблони та практики [тверда обкладинка]
• Голова Перші шаблони дизайну
• GOF Дизайн візерунка Біблія
• Перше вступ Роя Ошерова в одиничне тестування
• одиниця тестування моделей Біблії

Або для першого огляду:

• Твердий
• Шаблони тесту Xunit

Немає.

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

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

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

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

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

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

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

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

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

Тут також веселий образ ...

Я знайшов це зображення тут:
http://www.howtogeek.com/102420/geeks-versus-non-geeks-when-doing-repetitive-tasks-funny-chart/

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

Вони пропускають суть.

Тестування одиниць - це не відповідь. Тестування є.

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

Багато людей тестують вручну. Навіть переконливі ентузіасти TDD пройдуть ручне тестування, хоча вони іноді цього не визнають. Це не допоможе: перед тим, як зайти в конференц-зал, щоб продемонструвати програмне забезпечення своєму клієнту / начальнику / інвесторам / тощо. У цьому немає нічого поганого, і насправді було б шалено просто очікувати, що все пройде гладко, не пробігаючи його вручну - тобто тестуючи його - навіть якщо у вас є 100% покриття тесту на одиницю і максимальна впевненість у своїх тестах .

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

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

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

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

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

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

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

TL; DR: поки не переживайте про тестування одиниць . Спершу переживайте про тестування свого програмного забезпечення.

Це залежить

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

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

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

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

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

Ми приходимо до одного дуже важливого моменту - регресії . На місці, де я працюю, у нас є дві команди, які підтримують два додатки; один, написаний близько 5-6 років тому з дуже невеликим покриттям тестів на коди *, а другий - новішою версією першої програми з повнорозмірним набором тестів (одиниця, інтеграція та інше). Обидві команди мають спеціальні ручні (людські) тестери. Хочете знати, скільки часу потрібно для впровадження нової, досить основної функції для першої команди? 3 - 4 тижні. Половина цього часу - це "перевірка, чи все ще працює". Це зайнятий час для ручних тестерів. Телефонують дзвінки, люди засмучуються, знову щось порушується. Друга команда зазвичай займається такими питаннями менше ніж за 3 дні.

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

І останнє, але не менш важливе, коментар Брайана, який, на мою думку, знімає всю проблему:

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

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

_{* Вони повільно вводять все більше і більше тестів до своєї кодової бази, але всі ми знаємо, як зазвичай виглядає цей матеріал.}

пише тестові одиниці для веб-форм ASP.NET, що робиться часто, і якщо це так: як я можу вирішити проблему "динамічного середовища"?

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

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

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

Варто зазначити, що вони зазвичай сповільнюватимуть вас.

Це добре.

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

Я тільки що закінчив ступінь CS, і в даний час я працюю молодшим розробником .NET (в C # і, як правило, ASP.NET, веб-форми - не ASP.NET MVC). Ще коли я був в університеті, предмет опробовування перевірявся, але я ніколи не бачив його переваг.

Це тому, що ти ніколи не програмував великого.

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

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

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

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

-Чи б ви порадили мені почати писати одиничні тести?

Так, чорт візьми. Перш за все прочитайте «Тестовий розвиток» Бека .

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

Це сповільнює вас зараз. Але коли вам доведеться налагоджувати години замість днів, ви передумаєте.

будь-яка порада буде оцінена :)

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

Редагувати: я, звичайно, приєднався до dogpile TDD pro / con і пропустив питання №1:

1 - Впровадження модульних тестів у веб-формах ASP.net:

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

2 - Про те, чи варто в першу чергу одиничні тести:

Добре, повне розкриття інформації:

• Я здебільшого самоучка. Моя формальна підготовка зводиться до одного JavaScript, PHP та C # класу та мого особистого вивчення принципів OOP та читання з таких матеріалів, як шаблони дизайну.

Однак,

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

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

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

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

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

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

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

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

На мій досвід, одиничні тести дійсно дуже корисні, коли ви починаєте з них і залишаєтесь з ними, тобто Test-Driven Development. Ось чому:

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

• Единичні тести змушують задуматися про те, як буде використовуватися код, який ви збираєтеся написати . До того, як я дізнався TDD, були МНОГО часів, коли я писав код, очікуючи, що залежність працюватиме в одну сторону, а потім мені дали залежність, написану колегою, яка працювала зовсім по-іншому. Незважаючи на те, що це все ще можливо за допомогою TDD, тестовий пристрій, який ви пишете, змушує задуматися про те, як ви хочете використовувати об'єкт, який ви пишете, оскільки це приклад використання зазначеного об'єкта. Тоді, сподіваємось, ви запишете об'єкт таким чином, щоб його було легко споживати, і, таким чином, при необхідності адаптуватися (хоча програмування за заздалегідь заданими інтерфейсами є кращим загальним рішенням цієї проблеми, яка не вимагає TDD).

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

  Наприклад, скажіть, що вам потрібно створити новий об’єкт MyClass. Ви починаєте зі створення екземпляра MyClass. "Але MyClass не існує!", - скаржиться ReSharper. "Тоді створіть", ви говорите, натиснувши клавішу Alt + Enter. І заздалегідь у вас є визначення вашого класу. У наступному рядку тестового коду ви викликаєте метод MyMethod. "Але цього не існує!", - каже Решарпер. "Потім створіть", повторюєте ви, ще з одним Alt + Enter. Ви за допомогою декількох натискань клавіш визначили "скелет" вашого нового коду. Поки ви продовжуєте виконувати використання, IDE підкаже вам, коли щось не підходить, і зазвичай рішення є досить простим, що IDE або інструмент, що підключається до нього, знають, як це виправити.

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

• Блок тестів працює на багато порядків швидше, ніж будь-який ручний тест, про який ви могли придумати. Є сенс, який дуже швидко зустрічається у випадку великих проектів, коли витрата часу на тестування одиниць починає окупати себе за рахунок скорочення часу, проведеного вручну на тестування. ВИНАГАДАЙТЕ запускати код, який ви тільки що написали. Традиційно ви робили це вручну, запустивши велику програму, перейшовши по інтерфейсу користувача, щоб створити ситуацію, в якій ви змінили поведінку, а потім ще раз перевірити результати через інтерфейс користувача або у формі отриманих даних. Якщо код був TDDed, ви просто запустите тести одиниць. Я вам гарантую, якщо ви пишете хороші одиничні тести, останній варіант буде в багато разів швидшим, ніж перший.

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

  Якби розробникам довелося вручну знайти та протестувати всі рядки коду, на які могла вплинути потенційна зміна, нічого не було б зроблено, оскільки вартість визначення впливу зміни зробить цю зміну нездійсненною. Принаймні, нічого не було б ТВЕРДОМО і, таким чином, легко підтримуватись, тому що ви ніколи не наважуєтесь торкнутися чогось, що може бути використано в декількох місцях; замість цього ви скочуєте власне дуже подібне, але включене рішення для вашої мінорної зміни для цього випадку, порушуючи SRP та, ймовірно, OCP, і повільно перетворюєте свою кодову базу на ковдру з печворку.

• Блок тестів формує архітектуру типово вигідним чином . Одиничні випробування - це випробування, що виконуються ізольовано від будь-якої іншої логіки. Для того, щоб мати змогу перевірити свій код, тоді ви повинні написати код таким чином, що зможетеізолювати його. Хороші дизайнерські рішення, такі як нещільне з’єднання та ін'єкція залежності, таким чином, природним чином позбавляються від процесу TDD; залежності потрібно вводити так, щоб у тесті ви могли ввести "макет" або "заглушку", яка виробляє вхід або обробляє вихід для ситуації, що перевіряється, не створюючи "побічних ефектів". Звичайний менталітет TDD, як правило, призводить до "кодування до інтерфейсів", сутності слабкої зв'язку. Ці принципи хорошого дизайну дозволяють вносити зміни у виробництві, такі як заміна цілого класу, не вимагаючи змін великих масивів коду для адаптації.

• Експертні тести показують, що код працює, замість того, щоб довести код, працює . На перший погляд ви можете подумати, що це недолік; напевно, доказ кращий, ніж демонстрація? Теорія чудова; обчислювальна та алгоритмічна теорія є основою нашої роботи. Але математичний доказ коректності алгоритму не є доказом правильності реалізації . Математичне підтвердження лише показує, що дотримання коду до алгоритму повинно бути правильним. Тест одиниці показує, що написаний код насправді пише те, що ви думали, що це зробить, і, таким чином, свідчить, що це правильно. Це, як правило, набагато більше значення, ніж теоретичне підтвердження.

Тепер, все, що сказано, є недоліки в одиничному тестуванні:

• Ви не можете все перевірити. Ви можете сконструювати вашу систему, щоб мінімізувати кількість LOC, не охоплених одиничним тестом, але існують певні ділянки системи, які неможливо перевірити на одиницю. Ваш рівень доступу до даних може бути глузливий при використанні іншого коду, але сам рівень доступу до даних містить безліч побічних ефектів, і, як правило, неможливо одиничне тестування (найбільше?) Сховища або DAO. Аналогічно, код, який використовує файли, налаштовує мережеві з'єднання тощо, має вбудовані побічні ефекти, і ви просто не можете перевірити одиничний рядок коду, який це робить. Елементи інтерфейсу часто не можуть бути перевірені одиницею; ви можете протестувати методи, які використовуються за кодом, наприклад обробники подій, ви можете об'єднати тестові конструктори та переконатися, що обробники підключені, але просто не існує заміни коду для того, щоб користувач клацав мишкою на певний графічний елемент і спостерігав, як викликається обробник. Досягнення цих меж між тим, що можна, а що не можна адекватно перевірити, називається "вискоблюванням краю пісочниці"; поза цим моментом ви обмежуєтесь використанням тестів інтеграції, автоматизованих тестів прийняття та ручного тестування для перевірки поведінки.

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

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

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

• Для тестування блоку потрібно більше обладнання. Звичайним рішенням вищезазначеної потреби в дисципліні та природній схильності людей до ледачих і порівняльних результатів є "побудований бот", який виконує пакет програм "Постійна інтеграція", такий як TeamCity, CruiseControl тощо, який виконує одиничні тести. показники покриття коду та мають інші елементи управління, такі як "потрійний C" (відповідність умовам кодування, a la FxCop). Апаратне забезпечення для вбудованого бота повинно бути належним чином (у противному випадку воно не буде в курсі швидкості реєстрації кодів, яку вноситиме середня команда), а процедури реєстрації на боті повинні бути оновлені (якщо створюється нова бібліотека тестових одиниць, створюються сценарії, які виконують тести одиниць, слід змінювати, щоб вони переглядали цю бібліотеку). Це менше роботи, ніж це звучить, але, як правило, потрібна певна технічна експертиза з боку принаймні кількох людей у ​​команді, які знають, як працюють залізні зернистість різних процесів збирання (і таким чином можуть автоматизувати їх у сценаріях та підтримувати згадані сценарії). Він також все ще вимагає дисципліни у вигляді приділення уваги, коли збірка "ламається", і виправлення того, що призвело до розриву збірки (правильно), перш ніж перевірити щось нове.

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

• Тестування блоків, як правило, забороняє стилі кодування "швидкого розвитку додатків". Якщо ви пишете одиничні тести, ви не кодуєте "швидке та вільне". Це, як правило, добре, але коли ви перебуваєте у встановлений термін, встановлений поза вашим контролем, або ви впроваджуєте дуже невеликі зміни, і зацікавлена ​​сторона (або ваш начальник) задається питанням, чому все це сукупність має відбуватися саме змінити один рядок коду, це може бути просто нездійсненно писати та підтримувати належний набір тестових пакетів. Швидкі процеси, як правило, допомагають у цьому, дозволяючи розробникам сказати вимоги часу; Пам'ятайте, що продавець повинен зробити, це сказати "так ми можемо", і вони отримують перевірку комісії, якщо тільки в цьому процесі не беруть участь люди, які насправді повинні виконувати роботу, кажучи "ні, ми не можемо", і на це звертають увагу. Але, не кожен Agile, і Agile має свої обмеження.

Тести одиниці корисні при правильному використанні; є різні проблеми з вашою логікою.

"Коли я розвиваюсь, я переживаю багато спроб і помилок", - сказав Кевін.

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

s writing unit tests for ASP.NET web forms something that is done often

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

So, question number 2: Would you guys advise me to start writing unit tests?

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

На практичному рівні тестові одиниці можуть бути надзвичайно корисними з однієї дуже важливої ​​причини: Ви можете протестувати один біт коду за один раз.

Коли ви пишете цілу послідовність складних етапів і налагоджуєте їх наприкінці, ви зазвичай виявляєте багато помилок, і процес, як правило, складніше, тому що ви продовжуєте процес. У Visual Studio ви можете створити швидкий тест, трохи змінити його та запустити ТІЛЬКИ цей тест . Потім ви знаєте, що, наприклад, метод, що викликає цей метод, може покластися на нього. Так це підвищує впевненість.

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

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

Тестування блоків чудово підходить для середовищ спільної роботи : Якщо мені доведеться надати метод колезі, який використовує зовсім іншу технологію для шахти, як, наприклад, він викликає його з iOS, я можу швидко написати блок-тест, щоб побачити, чи метод, який він хоче a) Повертає правильні дані b) Виконує за його технічними умовами c) Не має неприємних вузьких місць.

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

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

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

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

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

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

Насправді ви можете ввести тестування модулів набагато простіше за допомогою шаблону MSP для ASP.NET, який може бути використаний при розробці веб-форм. Це запровадить розділення проблем та проблем ability to write essential unit tests.

Деякі посилання, які можуть бути корисними для пошуку, є:

• Початок роботи з тестуванням програми ASP.NET Webforms (MVP Pattern)
• Виконання та тестування перенаправлень за допомогою веб-форм ASP.NET MVP
• Модель перегляду презентацій з ASP.NET - CodeProject

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

З мого досвіду, так , одиничні тести корисні.

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

Блок тестування дає різні переваги:

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

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

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

Однак ...

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

Для простих додатків з невеликою кількістю шарів для тестування (Головне вікно -> підменю), можливо, компіляція для запуску для перевірки змін нормально.

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

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

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

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

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

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

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

Ви повинні знати, що має значення 10 + -5 класів або що ви робите зараз, і мати можливість перевіряти свій код з декількох точок огляду, кожна діаграма, яка представляє ТОЧНО точки зору, на які ви дивитесь, і ви вб'єте тисячі помилок на папері.

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

там просто набагато простіше ...

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

Я зробив код з 95 +% покриттів коду. Звичайно, я роблю одиничні тести іноді, особливо. для граничних перевірок в обчисленнях, але я ще не зіткнувся з серйозними регресіями (серйозні: не стираються за 24 години) за те, що не використовуються одиничні тести навіть для рефакторингу.

Іноді я не роблю жодного рядка коду протягом 3-4 днів прямо, просто малюю. Потім за один день набираю 1500-2000 рядків. На наступний день вони в основному готові до виробництва. Іноді пишуться одиничні тести (з 80 +% покриття), іноді (на додачу) тестерам пропонується спробувати її зламати, кожен раз деякі люди просять переглянути його, переглянувши його.

Я ще не бачу тих тестів, що знаходять щось.

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