Як далеко пройти з одиничними тестами

Питання, яке задавали багато разів раніше, але з конкретною розробкою mvc нахилу.

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

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

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

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

btw - перевірив це на ідеї:

http://dotnetslackers.com/articles/aspnet/Built-in-Unit-Test-for-ASP-NET-MVC-3-in-Visual-Studio-2010-Part-1.aspx

дивлячись на FWD до стабільних нинішніх результатів :)

[редагувати] - на користь єдиного (ну на даний момент одинокого !!) "закритого" виборця. це питання не є суб'єктивним. Я шукаю консенсус на дуже сфокусовану тему. Я не намагаюся розпалювати негативні пристрасті, я не хочу розкривати недоліки в технології - я ВЕЛИЧИЙ фанат. Тож, будь ласка, киньте ввічливий коментар на мою користь, якщо голосування завершиться, оскільки це може допомогти мені змінити питання, якщо є двозначність чи дезінформація. це питання може принести користь значній частині населення mvc.

Дякую!!

джим

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

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

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

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

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

Крім того, тести слід писати, коли:

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

2. Ви знайшли помилку, невдалий тест повинен демонструвати помилку. Коли помилка виправлена, тест повинен пройти.

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

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

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

З іншого боку, у вас може не вистачити часу або терпіння, щоб усе перевірити.

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

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

Запуск тестів одиниць із включеним покриттям коду у Visual Studio повинен дати точну (та графічну) інформацію про те, наскільки добре покрито ваш код.

Якщо ви не використовуєте вбудований фреймворк MSTest, вам може знадобитися переглянути продукт стороннього коду для роботи з NUnit або дотримуйтесь інструкцій тут: /programming/2665799/does-vs2010-code -покриття-підтримка-nunit