Я думаю, что существует немного Shu-Ha-Ri здесь. Вы задаете вопрос, который трудно объяснить. Это только после практикует и изо всех сил пытается применить TDD, который Вы получите Какой. До тех пор мы дадим Вам ответы, которые не имеют смысла, говоря, что Вы наполняете в рывке , Монады Являются Буррито . Это не поможет Вам, и мы будем походить на идиотов (монады являются ясно кругом лимонного шифона).

я рекомендовал бы получить Kent Beck книга TDD и работать через него и затем просто практиковать. "Нет никакой королевской дороги к Ri".

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

1) Определяют Граничные Объекты (Победа/Веб-формы, CustomControls и т.д.).

2) Определяют, что Объекты управления (Бизнес-расположенные на слое объекты)

3) Удостоверяются, что Записали Модульные тесты, по крайней мере, на открытые методы объектов управления, вызванные граничными объектами.

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

Протестируйте контракт интерфейса модуля, который Вы тестируете:

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

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

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

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

Примеры того, как сделать TDD: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

Также видит мой ответ от стандарты Записи для поблочного тестирования - это имеет примеры и ссылки для получения дополнительной информации. Вот также хорошие ссылки для следования: http://code.google.com/p/instinct/wiki/UsersGuide

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

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

, Например, кто-то изменил метод как "addElements (Строка [] элементы)". Они пытались использовать "для (интервал i=0; i< =elements.length; я ++)". За пределы исключение было выдано, когда модульные тесты бежали за регистрацией, и это было зафиксировано.

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

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

Я думаю, что можно получить большую часть выгоды от Модульного теста Разработкой через тестирование / Тест Первая Разработка. Вы должны первый тест записи затем писать код, которые проходят тест. И Что необходимо протестировать сначала?

я нахожу это действительно полезным для тестов записи из пользовательских историй. Большую часть времени я пишу Нисходящие тесты стиля из стартовых пользовательских историй. Например, наша пользовательская история containt такая задача:

1. то, Когда Пользователь Сохраняют Представление Порядка, Должно Отобразить информационное сообщение.

я обычно тест Записи для этой истории от уровня

  [Test]
    public void When_User_Save_Order_View_Should_Display_Information_Message()
    {
        using (mockRepository.Record())
        {
            repository.Save(order);
            view.Message= "Order saved successfully";
        }

        using (mockRepository.Playback())
        {
            presenter = new OrderSavePresenter(view, orderRepository);
            presenter.Save();
        }
    }

презентации/контроллера И затем я продолжаю к тесту записи на каждого классы, которые я дразнил или нуждался.

1. Для данного входа или состояния, необходимо протестировать это, возвращаемое значение метода - как Вы ожидали бы. Если Ваш метод возвращает много типов данных, необходимо проверить, что они все корректны.
2. Использование маленький набор демонстрационных данных прямо в Вашем тестовом сценарии. Ничего не загружайте из диска или базы данных. Передача в строке или конструкции тест возражает там в Вашем тесте. Учитывая, что маленький набор данных, Вы ожидаете иметь очень определенный результат Вашего метода, который Вы сравниваете со своим фактическим результатом. Вы хотите избежать большого количества кода, который вычисляет значения для Вас в Ваших тестах, потому что затем Вы имели бы к тестам записи на Ваши тесты к, удостоверяется, что они работают правильно!
3. Тест каждый бит кода, который Вы пишете. Для добавления записи (если Ваши тесты сцепляются до тестовой базы данных) можно просто запросить для последней вставленной записи, или сравнить общее количество numbver записей прежде и после и удостовериться увеличенный одним. Если Вы имеете, дразнить/блокировать платформу, можно пропустить базу данных и утверждать, что метод, который сохраняет вещи к базе данных, назвали. Для тестирования редактирования просто получают отредактированную запись, формируют базу данных снова и утверждают, что значение было изменено от его старого значения. Или если дразнить/блокировать, что метод для изменения значения атрибута правильно назвали.

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