Что вы тестируете своими юнит-тестами?

Question

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

1. Если у меня есть метод действия, который возвращает список данных, что я должен проверить? Только то, что имя представления является правильным, или я должен также проверить данные?
2. Если я тоже должен проверить данные, я не буду писать один и тот же код дважды? Какая польза от проверки данных, если я использую тот же метод для получения данных, с которыми сравниваю данные?
3. Должен ли я также проверить методы добавления / редактирования моих данных? Как проверить, что запись была добавлена ​​/ отредактирована / удалена, правильным образом?

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

В качестве примера - у меня есть (или я собираюсь написать) GuestbookController с методами просмотра, добавления, редактирования и удаления сообщений. Что мне нужно проверить? Как мне это сделать?

Answer 1

Модульное тестирование (UT)! = Test Driven Design (TDD)

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

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

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

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

Если вы просто пишете приложение для выполнения пяти конкретных задач, достаточно одного TDD.

Answer 2

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

Я бы порекомендовал достать книгу TDD Кента Бека и поработать с ней, а затем просто попрактиковаться. «Там нет королевской дороги в Ри.»

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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