Ответ 1

Единичное тестирование (UT)!= Испытательная конструкция (TDD)

Эта путаница, кажется, довольно распространена. UT - это охват кода. TDD занимается функциями. Они не то же самое [извините, Джоэл!]

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

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

При желании, используйте TDD, а затем вернитесь и завершите покрытие инструментами UT. Если вы создаете библиотеку классов или другой API для использования разработчиками, тем лучше тестовое покрытие; -)

Если вы просто пишете приложение, чтобы сделать пять конкретных вещей, TDD сам по себе должен быть достаточным.

Ответ 2

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

Я бы рекомендовал получить Kent Beck книгу TDD и работать через нее, а затем просто практиковать. "Там нет королевской дороги в Ри."

Ответ 3

Проверьте контракт тестируемого интерфейса модуля:

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

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

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

Ответ 4

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

1) Определите граничные объекты (Win/WebForms, CustomControls и т.д.).

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

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

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

Ответ 5

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

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

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

Ответ 6

• Для данного ввода или состояния вы должны проверить, что возвращаемое значение метода будет таким, как вы ожидали. Если ваш метод возвращает много типов данных, вы должны убедиться, что все они правильны.
• Используйте небольшой набор данных образца прямо в тестовом примере. Не загружайте ничего с диска или базы данных. Передайте строку или создайте тестовый объект в вашем тесте. Учитывая тот небольшой набор данных, который вы ожидаете получить от вашего метода очень конкретный результат, который вы сравниваете с вашим фактическим результатом. Вы хотите избежать большого количества кода, который вычисляет значения для вас в ваших тестах, потому что тогда вам придется писать тесты для своих тестов, чтобы они работали правильно!
• Проверьте каждый бит кода, который вы пишете. Чтобы добавить запись (если ваши тесты подключены к тестовой базе данных), вы можете просто запросить последнюю вставленную запись или сравнить общее число записей до и после и убедиться, что оно увеличилось на единицу. Если у вас есть фальшивка /stubbing framework, вы можете пропустить базу данных и утверждать, что был вызван метод, который сохраняет вещи в базе данных. Чтобы проверить редактирование, просто заново заново отредактируйте записанную форму записи базы данных и утвердите, что значение было изменено со своего старого значения. Или, если насмехается/стучит, что метод изменения значения атрибута был правильно вызван.

Но действительно, напишите тест на бит кода, который вы собираетесь написать. Наблюдайте, как это происходит. Затем напишите достаточно кода, чтобы он прошел. Теперь напишите еще один тест и повторите.

Ответ 7

Я думаю, вы можете получить большую выгоду от Unit Test с помощью Test Driven Development/Test First Development. Вы должны сначала написать тест, а затем написать код, который проходит тест. И что вы должны проверить первым?

Мне очень полезно писать тесты из рассказов пользователей. В большинстве случаев я пишу тесты стиля Top-Down от запуска пользовательских историй. Например, наша история пользователей содержит такую ​​задачу:

• Когда пользователь сохраняет вид заказа, должен отображать информационное сообщение.

Обычно я пишу тест для этой истории из уровня представления/контроллера.

  [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();
        }
    }

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

Ответ 8

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

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

Например, кто-то изменил метод типа "addElements (String [])". Они пытались использовать "for (int я = 0; я <= elements.length; я ++)". Исключение из-за пределов было брошено, когда модульные тесты запускались после регистрации и были исправлены.

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

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