Що я знайшов у TDD, так це те, що для налаштування тестів потрібен час, і, будучи лінивим, я завжди хочу писати якомога менше коду. Перше, що мені здається, це перевірити, що мій конструктор встановив усі властивості, але чи це надмірно?
Моє питання полягає в тому, на якому рівні деталізації ви пишете свої модульні тести?
..і є випадок тестування занадто багато?
Відповіді:
Мені платять за код, який працює, а не за тести, тому моя філософія полягає в тому, щоб тестувати якомога менше, щоб досягти певного рівня впевненості (я підозрюю, що цей рівень впевненості високий у порівнянні з галузевими стандартами, але це може бути просто пихатістю) . Якщо я зазвичай не роблю помилки (наприклад, встановлюю неправильні змінні в конструкторі), я не перевіряю це. Я, як правило, розумію помилки тесту, тому я дуже обережний, коли маю логіку зі складними умовами. Під час кодування в команді я модифікую свою стратегію, щоб ретельно протестувати код, який, як правило, ми помиляємось.
Різні люди матимуть різні стратегії тестування, засновані на цій філософії, але це здається мені розумним з огляду на незрілий стан розуміння того, як тести найкраще вписуються у внутрішній цикл кодування. Через десять або двадцять років ми, мабуть, матимемо більш універсальну теорію, які тести писати, які тести не писати, і як відрізнити різницю. Тим часом експерименти здаються в порядку.
Напишіть модульні тести для речей, які ви очікуєте зламати, та для крайніх випадків. Після цього слід додавати тестові приклади у міру надходження звітів про помилки - перед написанням виправлення помилки. Тоді розробник може бути впевнений, що:
Відповідно до доданого коментаря - я думаю, такий підхід до написання модульних тестів може спричинити проблеми, якщо з часом у даному класі буде виявлено багато помилок. Тут, мабуть, корисний розсуд - додавання модульних тестів лише для помилок, які можуть повторитися або де їх повторне виникнення може спричинити серйозні проблеми. Я виявив, що міра інтеграційного тестування в модульних тестах може бути корисною в цих сценаріях - тестування коду вище кодових шляхів може охоплювати кодові шляхи нижче.
Все повинно бути максимально простим, але не простішим. - А. Ейнштейн
Одне з найбільш неправильно зрозумілих речей про TDD - це перше слово в ньому. Тест. Тому й з’явився BDD. Тому що люди насправді не розуміли, що перший D - важливий, а саме Driven. Ми всі схильні думати трохи про тестування, а трохи про керування дизайном. І я припускаю, що це нечітка відповідь на ваше запитання, але ви, мабуть, повинні подумати, як керувати своїм кодом, замість того, що ви насправді тестуєте; у цьому вам може допомогти інструмент Покриття. Дизайн - це досить велике і проблематичне питання.
Тим, хто пропонує перевірити "все": усвідомлюйте, що для "повного тестування" такого методу int square(int x)потрібно близько 4 мільярдів тестів на загальних мовах та типових середовищах.
Насправді, це навіть гірше , ніж: метод void setX(int newX)також зобов'язаний НЕ змінювати значення будь-яких інших членів , крім x- ви тестування , що obj.y, obj.zі т.д. все залишаються незмінними після виклику obj.setX(42);?
Практично лише перевірити підмножину "всього". Як тільки ви приймаєте це, стає більш приємним розглядати питання про тестування неймовірно елементарної поведінки. Кожен програміст має розподіл ймовірностей місць помилок; розумний підхід полягає у тому, щоб зосередити свою енергію на тестуванні регіонів, де ви оцінюєте високу ймовірність помилок.
Класична відповідь - "перевірити все, що може зламатися". Я трактую це як таке, що тестування сетерів та геттерів, які не роблять нічого, крім set або get, є, мабуть, занадто великим тестуванням, не потрібно витрачати час. Якщо ваша IDE не напише їх для вас, ви можете також.
Якщо ваш конструктор, не встановлюючи властивостей, може призвести до помилок пізніше, тоді перевірка їх встановлення не є надмірною.
Я пишу тести, щоб висвітлити припущення класів, які буду писати. Тести відповідають вимогам. По суті, якщо x ніколи не може бути 3, наприклад, я збираюся переконатися, що існує тест, який охоплює цю вимогу.
Незмінно, якщо я не напишу тест для охоплення захворювання, він з’явиться згодом під час тестування на людині. Тоді я, безумовно, напишу, але я волів би зловити їх рано. Я думаю, справа в тому, що тестування є нудним (можливо), але необхідним. Я пишу достатньо тестів, щоб бути повними, але не більше того.
Частина проблеми з пропуском простих тестів зараз полягає в тому, що в майбутньому рефакторинг може зробити цю просту властивість дуже складною з великою кількістю логіки. Я думаю, найкраща ідея полягає в тому, що ви можете використовувати тести для перевірки вимог до модуля. Якщо, коли ви здаєте X, вам слід повернути Y, то це те, що ви хочете перевірити. Потім, коли ви змінюєте код пізніше, ви можете перевірити, що X дає вам Y, і ви можете додати тест на A, який дає вам B, коли ця вимога буде додана пізніше.
Я виявив, що час, який я витрачаю під час початкових тестів на написання розробки, окупається під час першого чи другого виправлення помилок. Можливість підібрати код, який ви не розглядали протягом 3 місяців, і бути впевненим, що виправлення охоплює всі випадки, і "ймовірно" нічого не порушує, надзвичайно цінна. Ви також побачите, що модульні тести допоможуть виявити помилки далеко за межами стека і т. Д. Побачення того, як окремі фрагменти програми працюють і не працюють, дає величезне розуміння того, чому вони працюють або не працюють в цілому.
У більшості випадків, я б сказав, якщо є логіка, протестуйте її. Це включає конструктори та властивості, особливо коли у властивості встановлюється більше ніж одна річ.
Що стосується занадто великого тестування, це спірно. Хтось сказав би, що все слід перевірити на міцність, інші кажуть, що для ефективного тестування слід перевіряти лише те, що може зламатись (тобто логіку).
Я б схилявся більше до другого табору, лише з власного досвіду, але якщо хтось вирішив перевірити все, я б не сказав, що це занадто ... трохи надмірного, можливо, для мене, але не надто для них.
Отже, ні - я б сказав, що не існує такого поняття, як "занадто багато" тестування в загальному розумінні, лише для окремих людей.
Тестова розробка означає, що ви припиняєте кодування, коли всі ваші тести проходять.
Якщо у вас немає тесту на властивість, то навіщо вам його застосовувати? Якщо ви не протестуєте / не визначите очікувану поведінку у випадку "незаконного" призначення, що має робити властивість?
Тому я повністю перевіряю кожну поведінку, яку повинен проявляти клас. Включаючи "примітивні" властивості.
Щоб полегшити це тестування, я створив простий NUnit, TestFixtureякий надає точки розширення для встановлення / отримання значення, бере списки дійсних та недійсних значень і має єдиний тест, щоб перевірити, чи властивість працює належним чином. Тестування одного властивості може виглядати так:
[TestFixture]
public class Test_MyObject_SomeProperty : PropertyTest<int>
{
private MyObject obj = null;
public override void SetUp() { obj = new MyObject(); }
public override void TearDown() { obj = null; }
public override int Get() { return obj.SomeProperty; }
public override Set(int value) { obj.SomeProperty = value; }
public override IEnumerable<int> SomeValidValues() { return new List() { 1,3,5,7 }; }
public override IEnumerable<int> SomeInvalidValues() { return new List() { 2,4,6 }; }
}
Використовуючи лямбди та атрибути, це може бути навіть написано більш компактно. Я вважаю, MBUnit має навіть певну підтримку для подібних речей. Справа в тому, що наведений вище код фіксує намір властивості.
PS: Ймовірно, PropertyTest також повинен мати спосіб перевірити, щоб інші властивості об'єкта не змінювалися. Хм .. повертаємось до креслення.
Я роблю модульний тест, щоб досягти максимально можливого покриття. Якщо я не можу досягти якогось коду, я переробляю фактори, доки покриття не буде максимально повним
Закінчивши тестовий тест, я зазвичай пишу один тестовий приклад, що відтворює кожну помилку
Я звик розмежовувати тестування коду та тестування інтеграції. Під час інтеграційного тестування (яке також є модульним тестом, але на групах компонентів, тому не зовсім те, що стосується модульного тестування) я перевірю на відповідність вимогам.
Тож чим більше я керую своїм програмуванням, пишучи тести, тим менше я турбуюся про рівень деталізації тестування. Озираючись назад, здається, я роблю якомога простішу справу, щоб досягти своєї мети перевірки поведінки . Це означає, що я створюю рівень впевненості, що мій код робить те, про що я прошу, але це не вважається абсолютною гарантією того, що мій код не містить помилок. Я вважаю, що правильний баланс - це перевірка стандартної поведінки, і, можливо, край або два випадки, а потім перейти до наступної частини мого дизайну.
Я погоджуюсь, що це не стосуватиметься всіх помилок і використовую інші традиційні методи тестування для їх виявлення.
Як правило, я починаю з малого, із входів і результатів, які, як я знаю, повинні працювати. Потім, виправляючи помилки, я додаю більше тестів, щоб перевірити те, що виправлено. Це органічно, і добре працює для мене.
Чи можете ви перевірити занадто багато? Можливо, але, мабуть, краще помилитися в цілому з обережністю, хоча це залежатиме від того, наскільки важливою є ваша програма.
Я думаю, ви повинні перевірити все, що є у вашому "ядрі" вашої ділової логіки. Getter і Setter теж, оскільки вони можуть прийняти від’ємне значення або нульове значення, яке ви, можливо, не хочете приймати. Якщо у вас є час (завжди залежить від вашого начальника), добре протестувати іншу бізнес-логіку та всі контролери, які викликають цей об'єкт (ви переходите від модульного тесту до інтеграційного тесту повільно).
Я не виконую модульних тестів простих методів сеттера / геттера, які не мають побічних ефектів. Але я тестую на модулі всі інші загальнодоступні методи. Я намагаюся створити тести для всіх граничних умов у моїх алгоритмах і перевірити охоплення своїх модульних тестів.
Це багато роботи, але я думаю, що це того варте. Я вважаю за краще писати код (навіть тестуючий код), ніж перебирати код у налагоджувачі. Я вважаю, що цикл побудови коду-розгортання-налагодження дуже трудомісткий, і чим більш вичерпними є тести модулів, які я інтегрував у свою збірку, тим менше часу я витрачаю на цей цикл побудови-розгортання-налагодження.
Ви не сказали, чому також кодуєте архітектуру. Але для Java я використовую Maven 2 , JUnit , DbUnit , Cobertura та EasyMock .
Чим більше я читаю про це, тим більше думаю, що деякі модульні тести схожі на деякі моделі: Запах недостатньої кількості мов.
Коли вам потрібно перевірити, чи ваш тривіальний геттер насправді повертає правильне значення, це тому, що ви можете змішати ім'я геттера та ім'я змінної члена. Введіть 'attr_reader: name' ruby, і цього більше не може бути. Просто неможливо в Java.
Якщо ваш геттер коли-небудь стане нетривіальним, ви все одно можете додати тест на це тоді.
Перевірте вихідний код, який вас турбує.
Не корисно тестувати ті частини коду, в яких ви дуже впевнені, якщо ви в цьому не помиляєтесь.
Перевірте виправлення помилок, щоб ви вперше та востаннє виправляли помилку.
Перевірте, щоб отримати впевненість у незрозумілих частинах коду, щоб отримати знання.
Тестуйте перед важким та середнім рефакторингом, щоб не порушити існуючі функції.
Ця відповідь скоріше для того, щоб з’ясувати, скільки одиничних тестів використовувати для даного методу, які ви знаєте, що хочете юніт-тести через його критичність / важливість. Використовуючи методику Basis Path Testing від McCabe, ви можете зробити наступне, щоб кількісно мати кращу впевненість у покритті коду, ніж просте "висвітлення виписки" або "покриття філій":