Чи потрібна нам реєстрація при виконанні TDD?

Виконуючи цикл Red, Green & Refactor, ми завжди повинні писати мінімальний код для проходження тесту. Це те, як мене вчили про TDD і про те, як майже всі книги описують процес.

А як же лісозаготівля?

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

Тому мої запитання:

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

Щось там мені не вистачає?

1) Чи потрібно реєструватися, якщо ми робимо TDD? чи не виявить невдалий тест, що не так із програмою?

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

2) Чи слід додати тест процесу реєстрації в кожному методі в кожному класі?

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

3) Якщо деякі рівні журналів відключені, наприклад, у виробничому середовищі, чи не введено це залежність між тестами та середовищем?

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

"Рівень журналу рейок - це інформація у виробничому режимі та налагодження у розробці та тесті" - http://guides.rubyonrails.org/debugging_rails_applications.html

Інші програми використовують аналогічний підхід.

4) Люди говорять про те, як журнали полегшують налагодження, але однією з головних переваг TDD є те, що я завжди знаю, що не так через невдалий тест.

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

Ведення журналу корисно для пояснення не виняткової поведінки програми:

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

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

Вихід вашої програми дорівнює 0, тоді як ми очікували, що це буде 1, чому це так?

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

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

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

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

Звичайно, критично важлива система може / повинна забезпечувати ключові показники продуктивності на деякій операційній панелі, але "класичний" журнал може забезпечити інший рівень деталізації.

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

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

Ведення журналу та TDD вирішують різні проблеми.

1. Якщо у вас немає 100% тестової обкладинки, що зазвичай не так, ви не можете знати, що ваше програмне забезпечення ніколи не вийде з ладу (EDIT: і - як сказано в коментарях - навіть якщо це станеться, це може викликати щось незалежне від вашого програмного забезпечення. крах); це те саме, що думати, що ти можеш робити програмне забезпечення, яке абсолютно не має помилок (навіть NASA не може цього зробити). Тож, принаймні, вам потрібно зафіксувати можливі збої у випадку аварії вашої програми, щоб ви могли знати чому.

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

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

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

Так, у загальному випадку вам потрібен журнал.

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

Але важливіша частина лісозаготівлі - це ремонтопридатність. Добре продумана реєстрація може відповісти на наступні питання:

• Додаток ще живий і б'є? (Реєструючи серцебиття кожні 1000 секунд.)
• Чи змінився показник роботи програми за останні 10 місяців? (За допомогою реєстрації статистичних даних про результати використання випадків використання.)
• Чи змінилося навантаження приладу за останні 10 місяців? (Реєструючи кількість запитів на тип запиту.)
• Чи змінив будь-який наш інтерфейс свої експлуатаційні характеристики?
• Чи викликає новий випуск інше використання, характерне для деяких підсистем?
• Ми під атакою DoS ?
• Які помилки трапляються?

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

Ведення журналу - це особливість, яка обробляє дезертирів, як і інші функції.

TL; DR: Ведення журналів та TDD є ортогональними. Наявність одного не має жодного стосунку до потреби іншого

Чи потрібно входити в систему, якщо ми робимо TDD? чи не виявить невдалий тест, що не так із програмою?

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

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

Чи слід додати тест для процесу реєстрації в кожному методі в кожному класі?

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

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

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

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

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

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

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

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

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