Тестова розробка - Сторінка 2 - Німецький форум Python
З 2002 р. Дискусії про мову програмування Python
Тестова розробка
Так, можливо, тести слід писати при розширенні програми. Це здається розумним способом визначити, чи варто тестування.
Де ви бачите переваги py-тесту чи носа перед unittest?
Хтось знає книгу Кент Бек, розроблену випробуванням?
Привіт, це добре законне запитання.
Я бачу це так, як це роблять BlackJack та Eydu.
Покриття, пов’язане з модульними тестами, перш за все повинно дратувати вас як програміста Схудніть на роботі, щоб визначити, чи ви охопили всі необхідні вам справи (які ви вважаєте важливими). У дуже великих додатках ви часто забуваєте писати модульні тести для важливих областей вашого програмного забезпечення, оскільки воно стає обширним, складним і заплутаним [1].
Висвітлення повинно позбавити вас від роботи з визначення територій, які ще не були охоплені модульними тестами [2]. Тоді ви можете використовувати згенерований звіт, щоб вирішити, які речі, на вашу думку, повинні бути висвітлені, а які для вас незначні. Незначні речі можуть бути, наприклад, справжніми тривіальними функціями, які раніше не змінювались і працювали "завжди". - Але, як BlackJack вже правильно вказав, диявол полягає в деталях. Часто це саме ті речі, де ви думаєте, що "вам не потрібно вписуватися", і там приховані помилки. Тому я зазвичай намагаюся (залежно від складності програмного забезпечення) досягти 100% покриття.
[1]: Здебільшого модульні тести написані не паралельно реальному програмному забезпеченню, а набагато пізніше = через тижні чи навіть місяці. Це те, що використовується тестова розробка, де спочатку пишуться модульні тести, а потім реалізуються відповідні речі.
[2]: Такі області знаходяться не тільки в межах функції, але представляють весь простір модуля: Іншими словами, функції, для яких взагалі не існує модульного тесту, відображаються вам покриттям. Наприклад, якщо у мене є модуль `` foobar '', є `` foo '' і `` bar '', і я написав лише модульний тест для `` foo '', подальше покриття показує мені, що `` бар '' не був виконаний (= перевірений) модулем модульного тестування.
Питання у вашому прикладі "доступ до бази даних і сокетів" полягає в тому, чим саме займається ваше програмне забезпечення? Якщо у вашому програмному забезпеченні використовуються лише ті компоненти (які не написані вами), вам також не доведеться їх тестувати! Це не ваша робота - охоплювати сторонні бібліотеки своїми модульними тестами. Для цього він просить написати Mocks.
Припустимо, у вас є функція або клас, які отримують доступ до сокетів через `socket` і, залежно від результатів, виконують певні дії або змінюють стан. Тепер виникає проблема, що коли ви використовуєте його для доступу до зовнішнього $ SERVER, який завжди повинен повертати певні дані. У цьому випадку ви абстрагуєте `сокет` та очікувані дані з $ SERVER настільки, що ваша функція працює так само, як якщо б ви насправді використовували` сокет` з $ SERVER.
Зокрема, це означає, що у вас є необхідне Переписування інтерфейсів `сокета`, які підключені до $ SERVER, просто повертаючи дані, які ви очікуєте від реального $ SERVER. Тоді все це обіцяють макет - манекен - який ви приписуєте своїй функції. Звичайно, вам доведеться відтворити цю манекен, щоб коди помилок/винятки, які ви очікуєте, були видані, як і в оригіналі.
І ось тут починає ускладнюватися. Тема насправді не зовсім тривіальна, і ви можете швидко досягти меж можливого (= пропорційність). Не даремно написання тестового середовища може швидко стати більш обширним і складним, ніж середовище для тестування. Тут вам слід зважувати вигоду та пропорційність у кожному конкретному випадку.
Ви також повинні розглянути, чи використовується програмне забезпечення в середовищі, що стосується безпеки. Там, в ІМО, зони, що стосуються безпеки, взагалі не слід тестувати з припущеннями, але слід створити реальне існуюче тестове середовище, спеціально підготовлене для цього.
Що все ще цікаво в контексті модульних тестів, які на 100% охоплюють все, так це те, що модульні тести також представляють специфікацію, так би мовити. Ви вказуєте (абстрактно) цілі інтерфейси до найдрібніших деталей; навіть якщо читається лише програмістом.
У цьому контексті було б цікаво, якби існували програми, які б також генерували специфікацію в читабельній формі з неї. Поки що ви можете обійтись, написавши для кожного тесту документацію, яка точно (кожна деталь) описує те, що робить тест, і ви створюєте програму, яка створює з неї специфікацію
Звучить смішно, але це мається на увазі серйозно. У цьому напрямку на складі Ruby є (окремі) міркування. Існує також пакет модульного тестування, який говорить не про написання модульних тестів, а про написання специфікацій - Гаразд, жодна свиня не може читати, крім тих, хто написав "специфікації", або ботаніків Ruby