Нова назва одиничних тестів [закрито]

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

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

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

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

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

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

І як нове ім'я для тестування одиниць, яке може пережити деякі заперечення, як щодо jContract? (Трохи орієнтований на Java, який я знаю :), або одиничні контракти?

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

Тестування слів у тестуванні одиниць змушує людей думати, що це тестування інтеграції чи тестування користувальницького інтерфейсу, оскільки це єдиний вид тестування, який вони коли-небудь робили. Це як введення Java в JavaScript.

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

Які причини ви / інші наводите, щоб не пройти тестування?

Залежності, які важко висміювати / підробляти /

Як ви думаєте, які їхні мотивації полягають не в одиничному тестуванні?

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

Концепція зміни імені вже розроблена. Це називається розвиненою поведінкою . Хлопці, які придумали це, помітили багато тих самих аргументів плюс неприродну придатність перевірити те, що ще не створено. Натомість їхня концепція полягає у написанні виконуваної специфікації (саме про те, що TDD насправді стосується).

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

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

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

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

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

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

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