Поешьте, Спите и Вдохните Поблочное тестирование/TDD/BDD [закрытый]

«PS: Мой менеджер говорит, что единственный способ получить мне повышение - это привести команду в TDD / BDD».

Единственный реальный способ получить команду делать что-то (не убивая вас в процессе) - значит ясно продемонстрировать им, что изменение их привычек принесет им пользу. Другими словами, напишите код. Много кода. Тонны кода. А затем, когда придет важное электронное письмо, которое радикально меняет спецификацию, покажите им, что вы можете легко изменить свой код с помощью рефакторинга и, что еще хуже, потому что вы были подготовлены к этому с вашими тестами. Полоса была зеленая, «взломать, взломать», КРАСНАЯ ПОЛОСКА !!!!, «взломать, взломать, взломать», зеленая полоса, иди домой ». Начните с тестов, а затем напишите код. Установите сервер сборки, на котором ПРОПУСКАЮТСЯ ТЕСТЫ!

Мне не нравится, когда люди говорят: «Практика X никогда не бывает плохой; если она не работает, вы делаете это неправильно». Извините, это похоже на любую другую чрезмерно рьяную религиозную догму. Я не куплюсь на это.

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

Любой, кто возражает против TDD, не должен автоматически обвиняться в пренебрежении качеством. («Так когда же вы перестали бить свою жену?») Дело в том, что в программном обеспечении есть ошибки, и стоимость их устранения нужно соизмерять с выгодой.

То же самое и в производстве. Допуски по размерам и отделке поверхностей не одинаковы, потому что иногда строгий допуск и зеркальная отделка не гарантируются.

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

Но я бы искоса посмотрел на любого товарища по команде, который начал приставать ко мне насчет «модульного тестирования еды, сна и дыхания и TDD».

Мой менеджер говорит, что единственный способ добиться для меня повышения - это привести команду в TDD / BDD.

Вы когда-нибудь думали, что, может быть, это звучит как отстой? Вы обнаружили, что ваше ворчание оттолкнуло остальную часть вашей команды?

Этот ответ мог потерять мне несколько очков репутации, но это нужно было сказать.

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

Боже, Grails имеет встроенную генерацию тестов. Если вы работаете в команде, которая использует Grails, насколько вам нужно больше продаж?

Найдите кого-нибудь, кто занимался TDD / BDD, и запишите с ним программу.

Помните, гибкость означает, что вы не полностью проданы ни одному конкретному методу. Если вы работаете над чем-то, где преимущества TDD того не стоят (например, редактирование методом проб и ошибок интерфейса Swing), то не используйте TDD.

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

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

Изучение того, как правильно настраивать хорошие модульные тесты - это сложная часть - некоторые из них вы выучите сами (пока продолжаете модульное тестирование), а остальное вы узнаете из поиска в Интернете.

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

ИМХО, метрики - лучший способ добраться отсюда туда. Следите за тем, насколько хорошо охвачен ваш код, сохраняйте дельты сложности кода для каждой фиксации, используйте средства запуска тестов, которые следят за вашим кодом на предмет изменений и постоянно повторно запускают соответствующие тесты. Никогда не позволяйте тестам превышать несколько строк, чтобы все ваши инструменты работали хорошо. И я бы рекомендовал раз в месяц брать выходной, чтобы пропустить свой код через тестер мутаций. Этот день следует посвятить только написанию тестов. Все это доставит вам боль, если вы еще не делаете хорошего TDD. Учитесь на боли, и очень скоро вы все сделаете правильно.

И никогда не упускайте из виду, для чего нужны тесты: для описания желаемого поведения. Это ваша исполняемая спецификация. (Именно поэтому мне нравится Огурец ; теперь вы можете заставить свой PHB писать тесты за вас! Ну, может, не совсем так, но близко!)

Лучшая практика ИМХО: делайте то, что практично, а не только потому, что это процесс. Не забывайте, какова цель написания приложений, и в мире бизнеса это не написание тестов. Не поймите меня неправильно, у них есть свое место, но это не должно быть целью.

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

Чтобы изучить это, я бы предложил (обобщая то, что сказали другие, и добавляю одно из своих):

1. посетите блоги и прочтите упомянутые выше книги
2. в паре с кем-нибудь, кто опытен в практике TDD

Я практиковал ката (упражнение) в боулинг самостоятельно около 20 раз (примерно по 30 минут каждое) до Я начал видеть свет. Начал с анализа описания дяди Боба здесь . На сайте codingdojo.org есть множество катов, включая решения и обсуждения. Попробуйте!

Приведу цитату из Nike: ПРОСТО СДЕЛАЙТЕ ЭТО.

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

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

YMMV.

Год назад я понятия не имел, как делать TDD (но очень хотел (как обидно)) и никогда не слышал о BDD... теперь я делаю и то, и другое навязчиво. Я работал в среде разработки .Net, а не Java, но я даже заменил кнопку "F5 - Run" макросом для запуска Cucumber (BDD) или MBUnit (TDD) в зависимости от того, что это - Feature/Scenario или Specification. Никакого отладчика, если это вообще возможно. $1 в банке, если вы используете отладчик (шутка (вроде как)).

Процесс очень классный. Фреймворк, который мы дополнительно используем, написан Оракулом, с которым мне посчастливилось столкнуться, и от которого я впитываю информацию, и этот фреймворк он/мы используем - MavenThought.

Все начинается с BDD. Наш BDD - это прямой огурец поверх железного рубина.

Feature:

Scenario: .... Учитывая, что я делаю бла...
Когда я делаю что-то другое... Тогда происходят удивительные вещи...

Сценарий: ...

И это не само модульное тестирование, но оно управляет функцией, сценарий за сценарием, и, в свою очередь, модульными (тестовыми) спецификациями... Итак, вы начинаете со сценария, и с каждым шагом, который вам нужно выполнить в сценарии, он управляет вашим TDD.

И TDD, который мы использовали, в некотором роде BDD, потому что мы смотрим на поведение, которое требует SUT (тестируемая система), и одно поведение указывается в каждой спецификации (файл класса "тест").

Пример:

Вот спецификация для одного поведения:

Когда создается тестируемая система.

Есть еще одна спецификация (файл класса C# When_blah_happens) для другого поведения при изменении свойства, но она выделена в отдельный файл.

using MavenThought.Commons.Testing;
using SharpTestsEx;

namespace Price.Displacement.Module.Designer.Tests.Model.Observers
{
    /// <summary>
    /// Specification when diffuser observer is created
    /// </summary>
    [ConstructorSpecification]
    public class When_diffuser_observer_is_created
        : DiffuserObserverSpecification
    {
        /// <summary>
        /// Checks the diffuser injection
        /// </summary>
        [It]
        public void Should_return_the_injected_diffuser()
        {
            Sut.Diffuser.Should().Be.SameInstanceAs(this.ConcreteDiffuser);
        }
    }
}

Это, вероятно, самое простое поведение для SUT, потому что в этом случае при его создании свойство Diffuser должно быть таким же, как у инжектированного диффузора. Мне пришлось использовать Concrete Diffuser вместо Mock, потому что в этом случае Diffuser является объектом Core/Domain и не имеет уведомления о свойстве интерфейса. В 95% случаев мы ссылаемся на все наши зависимости как Dep(), вместо того, чтобы инжектировать реальную вещь.

Часто мы имеем более одного [It] Should_do_xyz(), и иногда довольно много настройки, например, до 10 строк заглушек. Это просто очень простой пример без GivenThat() или AndGivenThatAfterCreated() в этой спецификации.

Для настройки каждой спецификации нам обычно нужно переопределить только пару методов спецификации:

GivenThat() ==> это происходит до создания SUT.

CreatSut() ==> Мы автоматически имитируем создание SUT с помощью StructureMap и в 90% случаев никогда не нужно переопределять этот метод, но если вы инжектируете Concrete конструктором, вам придется переопределить этот метод.

AndGivenThatAfterCreated() => это происходит после создания SUT.

WhenIRun() => если это не [ConstructorSpecification], мы используем это для запуска ОДНОЙ строки кода, которая является поведением, которое мы специфицируем для SUT

Также, если есть общее поведение двух или более спецификаций одного и того же SUT, мы переносим это в базовую спецификацию.

Все, что мне нужно сделать для запуска спецификации, это выделить ее имя, например "When_diffuser_observer_is_created" и нажать F5, потому что помните, для меня F5 запускает задачу Rake либо test:feature[tag], если Cucumber, либо test:class[SUT]. Для меня это имеет смысл, потому что каждый раз, когда вы запускаете отладчик, это выброс, код не создается (о, и это стоит $1 (шутка)).

Это очень, очень чистый способ спецификации поведения с помощью TDD и наличия очень, очень простых SUT и простых спецификаций. Если вы попытаетесь быть ковбоем-кодером и написать SUT дерьмово, с жесткими зависимостями и т.д., вы почувствуете боль от попыток сделать TDD и будете сыты по горло / сдадитесь ИЛИ перегрызете пулю и сделаете все правильно.

А вот собственно SUT. Мы немного пофантазировали и использовали PostSharp для добавления свойства notify changed на Diffuser, так что отсюда и Post.Cast<>. И опять же, именно поэтому я ввел Concrete, а не Mock. В любом случае, как вы можете видеть, недостающее поведение, определенное в другой спецификации - это когда что-либо меняется на Diffuser.

using System.ComponentModel;
using MavenThought.Commons.Events;
using PostSharp;
using Price.Displacement.Core.Products;
using Price.Displacement.Domain;

namespace Price.Displacement.Desktop.Module.Designer.Model.Observers
{
    /// <summary>
    /// Implementation of current observer for the selected product
    /// </summary>
    public class DiffuserObserver : AbstractNotifyPropertyChanged, IDiffuserObserver
    {
        /// <summary>
        /// gets the diffuser
        /// </summary>
        public IDiffuser Diffuser { get; private set; }

        /// <summary>
        /// Initialize with a diffuser
        /// </summary>
        /// <param name="diffuser">The diffuser to observe</param>
        public void Initialize(IDiffuser diffuser)
        {
            this.Diffuser = diffuser;
            this.NotifyInterface().PropertyChanged += (x, e) => this.OnPropertyChanged(e.PropertyName);
        }

        /// <summary>
        /// Gets the notify interface to use
        /// </summary>
        /// <returns>The instance of notify property changed interface</returns>
        protected INotifyPropertyChanged NotifyInterface()
        {
            return Post.Cast<Diffuser, INotifyPropertyChanged>((Diffuser)Diffuser);
        }
    }
}

В заключение хочу сказать, что этот BDD / TDD стиль разработки просто потрясающий. Это заняло один год, но я полностью перешел на этот стиль. Я бы не научился этому самостоятельно. Я почерпнул все от Оракула http://orthocoders.com/.

Красная или синяя таблетка, выбор за вами.

Я занимаюсь TDD пару лет, но в последнее время я начал больше интересоваться способом BDD для моего дизайна и разработки. Ресурсы, которые помогли мне начать работу с BDD, были прежде всего блогом Дэна Норта («основателя» BDD). Взгляните на Введение в BDD . Также есть «официальная» BDD Wiki на behavior-driven.org с хорошим постом, который стоит прочитать.

Одна вещь, которая мне показалась очень сложной, когда я начинал с BDD (и все еще нахожусь немного сложной), - это то, как сформулировать эти сценарии, чтобы сделать их подходящими для BDD. Скотт Беллвар - человек, хорошо разбирающийся в BDD (или Context-Spesification, как он любит это называть), и его статья Behavior-Driven Development в Code Magazine очень помогла мне понять образ мышления и формулировки BDD. пользовательские истории.

Я бы также порекомендовал сделать скринкаст TekPub Дизайн, управляемый поведением, с помощью Specflow Роба Конери. Отличное введение в BDD и инструмент (SpecFlow), очень хорошо подходящий для выполнения BDD на C #.

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

• Эффективная работа с устаревшим кодом Майкла Фезерса; Обязательно прочтите, если вы работаете над устаревшим кодом (не все ли?) И хотите протестировать его
• Искусство модульного тестирования: с примерами в.Сеть Роя Ошерова; Если вы новичок в модульном тестировании, это книга , с которой вы начнете
• Разработка через тестирование: на примере Кента Бека; Если вы изучаете TDD, почему бы не получить его из самого источника? Хорошая книга - легко читается, с хорошим юмором и прекрасными мыслями.
• Чистый код: руководство по гибкому разработке программного обеспечения Роберта К. Мартина; Если Кент Бек описывает как TDD, то дядя Боб описывает почему .