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

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

Тепер, неминуче, я впевнений, що мене запитають, чому мені потрібно більше ніж два-два дні, щоб написати код, оскільки частини того, з чим я буду взаємодіяти, вже є в системі (хоча і без тестів, і дуже щільно) разом), і коли я перевіряю код, мене запитають, що це за проект "Тести". Я можу пояснити основи тестування, але я не можу пояснити фактичні переваги так, як зрозуміли б інші (оскільки вони думають, що тестування вимагає від вас запустити додаток самостійно, оскільки часто власне інтерфейс має значення для визначення того, чи функція "працює" " чи ні). Вони не розуміють ідеї вільної зв'язку (це чітко видно з того, що нічого невільно пов'язане; немає навіть інтерфейсів поза кодом, який я написав), тому намагаючись використати це як користь, певно, заробив би мені "А?" вид вигляду, і знову ж таки я не можу бути таким розкутим, як хотілося б, не переробляючи декілька існуючих модулів і, ймовірно, вводити якийсь контейнер IoC, який би розглядався як витрата часу, а не "програмування".

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

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

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

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

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

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

Дивіться також цю пов’язану тему: Автоматичне тестування блоку, тестування інтеграції або тестування приймання .

І більш ранній з SO: Що таке одиничне тестування?

Повторний фактор без страху

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

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

Я міг би гуляти на більше, але це добре вкритий грунт, такий як дядько Боб на TDD та Мартін Фаулер на TDD .

Залежності

О, я додам ще одну річ. Це покаже їм, як TDD примушує гарний дизайн, який дозволяє вам чисто вирішувати залежності.

Боб: "О,%% p! Боси просто змусили всіх нас використовувати MS SQL Server 2008" Джейн: "Це нормально, шкода зведена до мінімуму, тому що ми робимо наш джерело даних та наші DAO-класи, я радий, що TDD заохочує нас по цьому шляху ».

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

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

Зробіть математику

• t _mt = час, необхідний для ручного тестування всього, на що мислимо, це може вплинути
• t _wt = час, необхідний для написання тестів

• k = кількість разів, напевно, доведеться протестувати все, перш ніж випустити новий код

  якщо (t _wt <t _mt ) або (t _wt <(k * t _mt )), то це не-мозок: написання тестів пришвидшить розвиток.

інакше подивіться на співвідношення (t _wt / (k * t _mt )). Якщо це дуже велика кількість, тоді чекайте іншої можливості; інакше виправдайте переваги регресійного тестування.

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

Примітка 2: час для проведення тестів не має значення , оскільки вони автоматизовані. Ви можете зробити ще щось продуктивне під час виконання тестів, якщо тільки тести не займуть стільки часу, що вони змусять вас пропустити термін. Що рідко.

Одне з пропозицій, якщо ви є магазином Microsoft: знайдіть документацію на MSDN, яка рекомендує тестування одиниць або купірування, як найкращу практику (я впевнений, що існує декілька випадків цього ) та вкажіть на це, якщо є конфлікти.

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

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

Ключове слово тут - еволюція, а не революція.