Я ніколи не використовував автоматизований тестовий механізм в жодному зі своїх проектів, і я відчуваю, що мені багато чого не вистачає. Я хочу вдосконалити себе, тому я повинен почати вирішувати деякі проблеми, якими я нехтував так, і намагаюся Git замість того, щоб застрягти на SVN.
Який хороший спосіб дізнатися TDD? Можливо, я буду використовувати Eclipse для програмування на Java. Я чув про JUnit, але не знаю, чи є ще щось, що я повинен розглянути.
Відповіді:
Ви можете почати, працюючи над кодуванням каталів . Виберіть алгоритм (наприклад, перетворення цифр у римські цифри, забивання гри в боулінг, гра життя Конвей тощо) та спробуйте використовувати TDD для роботи над рішенням.
Ваша структура рішення, ймовірно, буде дуже простою (набагато простішою, ніж ваш виробничий код у реальному світі): один клас для тестового кріплення та один клас, що містить алгоритм, що перевіряється. І тестований клас, який не має залежностей, є ще одним плюсом. Ви можете скористатися простотою цього налаштування, щоб швидко отримати призупинення циклу червоно-зеленого рефактора.
Який інструмент ви використовуєте для своїх каталогів TDD насправді не має значення, якщо ви дотримуєтесь принципів. Однак плагін JUnit для Eclipse дуже простий у використанні, тому це відмінний вибір.
Ознайомтеся з AAA , прочитайте про нього, прочитайте про проблеми, що виникають із тестовою розробкою ( дизайн для перевірки та інструментів високої вартості, щоб дизайн не мав значення). Вивчіть введення залежностей, щоб усунути зовнішні залежності для тестування стало простіше.
Ось хороший огляд приміток, які я взяв під час читання «Тестування мистецтва одиниці»
http://imaginarydevelopment.blogspot.com/2010/01/unit-testing-reference.html
Дійсно немає заміни, щоб просто взяти тестовий джгут (як NUnit), прочитати частину літератури і потім забруднити руки.
Як одного разу сказав Джеймс Т. Кірк, "Ми вчимося, роблячи справи".
Настійно рекомендую цю книгу: Зростаюче об’єктно-орієнтоване програмне забезпечення, кероване тестами
Він має відпрацьований приклад, що проходить через книгу і дає дуже узгоджене уявлення про те, коли слід створити тест, що вони повинні містити і як вони повинні бути побудовані та відновлені.
Перевірте це посилання . Це блог Боб Мартіна на TDD - чудовий матеріал для того, щоб зрозуміти (або дати вам ще один потенційний досвід) мислення в TDD.