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

Question

Разработка на основе тестирования в Википедии говорит, что сначала разработайте тест, который не пройдёт, потому что эта функция не существует.Затем создайте код для прохождения теста.Как выглядит этот тест?

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

Может кто-нибудь привести пример?

Например, еслиЯ добавляю функцию кнопки выхода в веб-приложение, а затем тест попадет на страницу в поисках кнопки?или что?

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

Answer 1

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

Вы можете использовать WATIN или WebAii для проведения такого рода теста. Вы могли бы тогда:

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

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

Answer 2

Как выглядит этот тест?

Тест состоит из 3 частей.

1. устанавливает контекст
2. выполняет действие
3. утверждает, что действие сделало то, что должно было сделать

Как определить, какой тест лучше всего будет представлять функцию, которую вы хотите создать? Тесты не основаны на функциях (если вы не говорите о высокоуровневой инфраструктуре, такой как cucumber ), они основаны на «единицах» кода. Обычно модуль - это функция, и вы напишите несколько тестов, чтобы утверждать, что все возможные варианты поведения этой функции работают правильно.

Может кто-нибудь привести пример? Это действительно зависит от используемой вами структуры. Лично мой любимый это musta, который является расширением для ruby ​​Test :: Unit framework

Вот пример из readme. В случае структуры BDD, подобной этой, контекстная настройка происходит в своем собственном блоке

class UserTest < Test::Unit::TestCase
    context "A User instance" do
      setup do
        @user = User.find(:first)
      end

      should "return its full name" do
        assert_equal 'John Doe', @user.full_name
      end

      context "with a profile" do
        setup do
          @user.profile = Profile.find(:first)
        end

        should "return true when sent #has_profile?" do
          assert @user.has_profile?
        end
      end
    end
  end

Например, если я сделаю функцию кнопки выхода из системы для веб-приложения, будет ли тест попадать на страницу в поисках кнопки? или что?

Существует 3 основных типа тестов.

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

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

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

Answer 3

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

Сначала напишите тест с надписью f(10) == 11, затем выполните тест с надписью f(10) != 10. Затем напишите функцию, которая проходит эти тесты. Если вы понимаете, что функция требует больше возможностей, добавьте больше тестов.

Answer 4

Зависит от того, какую платформу вы используете, и как будут выглядеть ваши тесты. TDD намного сложнее в веб-формах ASP.NET, чем ASP.NET MVC, потому что очень трудно смоделировать среду HTTP в веб-формах для получения ожидаемого состояния Session, Application, ViewState и т. Д., В отличие от ASP.NET MVC.

Типичный тест строится вокруг Arrange Act Assert.

// Arrange
... setup needed elements for this atomic test

// Act
... set values and/or call methods

// Assert
... test a single expected outcome

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

Answer 5

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

Веб-приложения общеизвестно сложны для модульного тестирования из-за всей контекстной информации, обычно необходимой для выполнения серверного кода на веб-сервере. Однако типичный пример будет макетировать эту информацию и вызывать логику выхода из системы, а затем проверять, что был возвращен правильный результат. Свободным примером является типовой тест MVC с использованием NUnit и Moq :

[Test]
public void LogoutActionShouldLogTheUserOut()
{
    var mockController = new Mock<HomeController>() { CallBase = true };
    var result = mockController.Object.Logout() as ViewResult;

    Assert.That(result.ViewName == "LogoutSuccess", 
                "Logout function did not return logout view!");
}

Это бесполезный пример, потому что на самом деле он просто проверяет, что было возвращено представление «LogoutSuccess», а не что какая-либо логика выхода была выполнена. В реальном тесте я высмеивал HttpContext и проверял, что сеанс был очищен или что-то еще, но я просто скопировал это;)

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

Answer 6

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

нажатие на кнопку выхода из системы было бы больше похоже на приемочный тест - что тоже хорошо, и (на мой взгляд) хорошо в рамках TDD, но он проверяет ДВЕ функции: кнопку и конечное действие