Как перенести вашу парадигму на разработку, основанную на тестировании?

Question

Я слышал о разработке через тестирование уже пару лет, и я никогда не обращал на это внимания с практической точки зрения до недавнего времени, когда я начал больше интересоваться .NET MVC. Я много играл с MVC Storefront Sample , и я понимаю, насколько классным и полезным может быть подход, основанный на тестировании. Тем не менее, я программировал с использованием подхода «последний тест» уже давно, и когда дело доходит до бизнеса, я всегда могу наилучшим образом оценить свои усилия с помощью подхода, который мне наиболее знаком.

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

Каков наилучший для меня способ изменить свое мышление при планировании создания приложения, чтобы я смог в кратчайшие сроки стать эффективными с разработкой на основе тестирования?

Answer 1

Вы все еще можете проверить последний. Это нормально. Мы вас простим.

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

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

В конце концов, вы можете перейти к коду-немного-тест-немного. Тогда немного-немного-тестируй.

Чистый тест управляемый разработка идеальна. Прагматично, большинство людей тестируют немного кода. Больше похоже на тест-рулевое управление или тест-ориентирование, чем на тест-драйв.

Начните сейчас. Проверьте все, что у вас есть под рукой.

Answer 2

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

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

Мой любимый псевдокод в конце этого пункта в FAQ JUnit . Настроение тестового примера - это бесконечный цикл. Прыгайте куда угодно, любой тест, который вы напишете, поможет, и вы не пожалеете об этом.

Answer 3

Вам нужно тренироваться .

Вы можете начать с первого теста . Разработайте код так, как вы это обычно делаете, возможно, не в деталях, и начните сначала реализовывать его тест: начните с класса, который не имеет зависимостей, посмотрите, как его можно протестировать, запишите список тестов, о которых вы можете подумать. Начните писать самый простой тест. Затем напишите достаточно кода, чтобы он прошел. Перейдите тест по списку и напишите его, напишите код.

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

Я бы рекомендовал вам прочитать Test Driven Development ; это очень хорошее введение в TDD, а также содержит множество справочных материалов (называемых шаблонами).

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

Еще несколько советов, как только вы начнете:

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

• Старайтесь никогда не писать ни одной строки кода без неудачного теста - это конечная цель.

Answer 4

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

Также помните, что TDD - это скорее стратегия проектирования, чем стратегия тестирования. Будьте открыты к тому, что тесты говорят вам о рабочем коде. Всегда беспощадно рефакторинг - особенно в начале, если слишком сомневаешься в ошибке.

Если вы можете найти единомышленников, подумайте о том, чтобы провести додзе кодирования; это отличный, интересный способ выучить новый навык программирования: http://codingdojo.org/

Answer 5

Даже если вы сначала пишете код, спросите себя, пишите ли он: "Это тестируемый?" Если это не так, вы можете переосмыслить свой дизайн для конкретного фрагмента кода, который вы пишете. Если это так, то продолжайте, закончите и напишите несколько тестов позже. Я сейчас в коде-немного-тест-мышления.

Answer 6

В дополнение к тому, что говорит С.Лотт, посмотрите на структуру MVC Storefront.

Как они справляются с тестированием с данными, поступающими из базы данных? Как они справляются с проверкой правильности работы контроллера? Как они справляются, когда у класса есть другие зависимости?

Рассмотрение того, как TDD требует от вас структурирования программы, действительно поможет, если вы освоите основы (???) Unit