Упражнения для применения передовых методов, таких как TDD и Mocking

Question

Я ищу ресурсы , которые предоставляют фактический план урока или путь , чтобы поощрять и усиливать такие методы программирования, как TDD и mocking . Есть множество ресурсов, которые показывают примеры, но я ищу что-то, что на самом деле обеспечивает прогрессию , которая позволяет изучать концепции вместо принудительной эмуляции .

Моя основная цель - ускорить процесс, чтобы кто-то мог понять концепции, лежащие в основе TDD, и фактически быть эффективным в их реализации. Есть ли такие бесплатные ресурсы?

Answer 1

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

Краткий список советов:

• Вы должны быть лидером, вы должны стать опытным, прежде чем вы сможете убедить других, вы должны быть в состоянии показать другим путь и уладить их неопределенности.

• Сначала станьте опытным в написании юнит-тестов самостоятельно

  • Практикуйтесь в написании тестов для существующих методов. Вероятно, вы будете биться в тупик, пытаясь протестировать большую часть кода - это не потому, что тестирование сложно или вы не можете понять тестирование; это более вероятно, потому что ваш существующий код и стиль кодирования не очень тестируемы.

  • Если вам трудно начать работу, найдите самые простые методы, которые вы можете использовать, и используйте их в качестве отправной точки.

• Затем сконцентрируйтесь на улучшении тестируемости кода, который вы создаете

  • Самый большой совет: делайте вещи меньше и ближе к делу. Это большая перемена - это самая трудная часть, которую нужно заставить себя сделать, и еще труднее убедить других.

Лично у меня был «момент ясности», когда я читал книгу «Чистый код» Боба Мартина; В первой главе рассказывается о том, как будет выглядеть чистый метод, и в качестве примера он берет метод ~ 40 строк, который визуально напоминает то, что я произвел, и превращает его в класс, который едва ли больше по количеству строк, но не состоит из ничего но методы размера укуса, которые, возможно, 3-7 строк каждая.

Глядя на эти крошечные методы, он вдруг обнаружил, что краеугольный камень модульного тестирования «каждый тест проверяет только одну вещь» легче всего достичь, когда ваши методы выполняют только одну задачу (и делают это одну вещь, не имея 30 внутренних механизмов играть).

Хорошо, что вы можете немедленно начать применять свои выводы; попрактикуйтесь в написании небольших методов и небольших классов и тестировании по пути. Вы, вероятно, начнете медленно и довольно быстро добьетесь нескольких препятствий, но первые пару месяцев помогут вам ориентироваться в правильном направлении.

Answer 2

Вы можете попробовать (или принять у себя, если рядом никого нет!) Кодирование dojo

Я присутствовал на одном из таких упражнений, и было интересно изучать TDD.

Answer 3

Книги - это всегда хороший ресурс - хотя и не бесплатный - они могут стоить вашего времени на поиск хороших бесплатных ресурсов - за те деньги, которые стоят эти книги.

"Разработка через тестирование на примере" от Кента Бека.

"Разработка через тестирование в Microsoft .NET" Джеймсом В. Ньюкирком и Алексеем А. Воронцовым

пожалуйста, не стесняйтесь добавлять в этот список

Answer 4

Вундеркинды отлично работают с метриками, хороши они для них или нет!

Вы можете использовать это в своих интересах. Настройте сервер CI и завершайте сборку всякий раз, когда покрытие кода падает ниже 50 процентов. Дайте им знать, что порог будет увеличиваться на 10 процентов каждый месяц до 90. Возможно, вы могли бы использовать некоторые хуки коммитов, чтобы они не могли проверять код для начала, но я никогда не пробовал это сам.

Сообщите им, что охват команды будет применяться в любых обзорах эффективности и т. Д. Подчеркивая, что это охват команды, вы должны получить давление со стороны сверстников, помогающее обеспечить хорошее покрытие.

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

Как правило, как только у людей появляется что-то в их процессе, они хотят сделать что-то настолько легко / эффективно, насколько это возможно. TDD - это самый простой способ написать код с высоким охватом, поскольку вы не пишете строку кода без ее покрытия.

Answer 5

Одна вещь, с которой я работал, которая помогла мне оценить TDD больше, была NHibernate и Unit of Work Pattern . Хотя это специфично для NHibernate и .NET, мне понравилось, как это было организовано. Используя TDD, вы разрабатываете что-то (UnitofWork), которое на самом деле полезно, а не какой-то простой пример «вот так выглядит насмешка».

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

Answer 6

Найди кого-нибудь с опытом и поговори с ним. Если нет локальной группы разработчиков, то создайте ее.

Вам также следует попытаться отодвинуть вещи слишком далеко, чтобы начать, а затем научиться отступать. Например, вся эта шутка началась, когда кто-то спросил: «Что делать, если мы программируем без геттеров».

Наконец, научитесь «слушать тесты». Когда тесты выглядят ужасно, подумайте, виноват ли их код, а не ваша методика тестирования.