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

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

Мої запитання полягають у тому, які реальні світові переваги належного тестування одиниць я можу використати для відштовхування? Чи є? Чи я просто буду стикером, кажу, що погані тести (навіть якщо вони працюють) погані? Чи покриття кодом так само ефективно?

• Ресурси

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

• Надійність

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

• Додаткове обслуговування

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

• Паралельність

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

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

Мої запитання полягають у тому, які реальні світові переваги належного тестування одиниць я можу використати для відштовхування?

Хороші одиничні тести (за чистим кодом та в інших місцях):

• Швидкий
• Незалежний
• Повторне
• Самовивірка
• Своєчасно

Відсутність справжніх одиничних тестів порушує перші три (і, як правило, останні). Це призводить до деяких досить значних проблем:

1. Ваші тести повільні. Повільні тести запускаються нечасто. Тести, які не проводяться, майже марні.
2. Ваші тести можуть вийти з ладу через причини, не пов'язані з кодом, який ви тестуєте. Це набагато важче з’ясувати, чому тести не вдалися, витрачаючи час і спонукаючи людей звинувачувати навколишнє середовище, а не код.
3. У міру зміни бази даних ваші результати змінюються. Отримати деяку базу даних у відомому хорошому послідовному, підтримуваному стані для тестів - втомлює, дратує та схильність до помилок.

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

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

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

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

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

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

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