Чи вважається "поганою практикою" перевіряти вміст / кодування файлу в одиничних тестах?

Трохи контексту: раніше мені довелося оновити деякий код SQL, який надав інший мій колега, і оскільки це досить великий сценарій, він зберігається як окремий файл (який потім читається та виконується під час виконання). Роблячи це, я випадково знову ввів два помилки, які у нас були кілька місяців тому, а саме:

• З будь-якої причини файл ASCII був закодований в UTF-16 (колега надіслав мені файл, який, можливо, спричинив його).
• У скрипті були відсутні початкові SETзаяви (необхідні через деякі речі драйверів на виробництві, але не на чистій установці локально).

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

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

"Ці речі не належать до одиничних тестів"

"Одиничні тести повинні використовуватися лише для перевірки потоку вашого коду"

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

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

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

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

Яку проблему я намагаюся вирішити?

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

Які інструменти / процеси доступні для вирішення проблеми?

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

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

Одиничні тести вирішують проблему лише для вашого поточного файлу.

Як я повідомляю про потребу в інструменті?

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

У керівника вашої команди можуть бути деякі ідеї, які ви (або я) не розглядали, які можуть вирішити проблему більш коректно.

Неправильно називати тести, які отримують доступ до файлів "Тести одиниць".

Він: "Ці речі не належать до одиничних тестів"

Ви: "Має сенс, але я не міг знайти кращого місця, щоб розмістити їх. Де вони належать?"

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

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

Про це говорить Майкл Перо у своїй книзі «Ефективна робота зі спадковим кодексом»:

У цій галузі люди часто повертаються вперед і назад щодо того, чи є конкретні тести одиничними тестами. [...] Повертаюсь до двох якостей: чи швидко проходить тест? Чи може це допомогти нам швидко локалізувати помилки?

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

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

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

Ви можете назвати їх інтеграційними тестами; Безумовно, вони ближче до цієї точки зору, ніж одиничні тести.

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

Тест одиниці - це тестування методу або "одиниці" коду. Ви перевіряєте найменшу групу логіки та коду у вашому програмному забезпеченні.

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

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

Ваш SQL є кодом, як і будь-яка мова нижчого покоління, на зразок C # або Java, і його слід перевірити як такий. А перевірка та перевірка належать до всіх рівнів тестування. Отже, кодування та оператори SET включені, але не обов'язково перевіряються виключно. Загальні речі, такі як закінчення рядків або додавання, зазвичай можуть просто використовувати гак або функцію SCM.

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

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

Повернення до відсутніх операторів SET - вони допомагають повідомити про багато можливостей введення та виведення для тестування. Який тест ви б написали, що не вдасться, якби ви пропустили будь-який обраний SET?

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

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

У будь-якому випадку це може бути не одиничний тест, але це корисний тест. І якщо ви використовуєте блок тестування одиниць, який дозволяє зробити корисний тест (це не одиничний тест), чому б не використати блок тестування одиниць?

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

git add -p

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

У випадку, якщо кодування цілого файлу зміниться, все-таки відбудеться git add -pщось інше: алгоритм не зможе відрізняти старий і новий файл, а отже , взагалі нічого не додасть. Тоді це буде видно в іншій команді, яку я виконував би перед будь-яким вчиненням, а саме

git status

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

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

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

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

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

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

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

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

У минулому я широко використовував такий вид тесту - вони врятували нам неабиякий шматок болю.

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

SQL - це не те, що можна перевірити поодиноко, тому будь-який тест SQL не є саме тестовою одиницею, і, за винятком операторів SELECT, майже певний може мати побічний ефект. Ми можемо назвати це інтеграційним тестом, а не одиничним тестом.

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

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