Как к методам комплекса модульного теста

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

Я предпочитаю делать следующее.

1. Создают электронную таблицу с правильными ответами. Однако комплекс, которым это должно быть, не важен. Вам просто нужны некоторые столбцы со случаем и некоторые столбцы с ожидаемыми результатами.

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

2. Создают небольшую программу, которая читает электронную таблицу и пишет упрощенные, реалистичные unittest случаи. Вы хотите свои случаи, разделенные вниз к

   def testCase215n( self ):
       self.fixture.setCourse( 215 )
       self.fixture.setBearing( 45 )
       self.fixture.calculate()
       self.assertEquals( "N", self.fixture.compass() )
   

[Это - Python, та же идея содержала бы для C#.]

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

я использую маленькую программу Python с xlrd и шаблонным генератором Мако, чтобы сделать это. Вы могли сделать что-то похожее с продуктами C#.

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

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

Я полагаю, что Ваше решение прекрасно, несмотря на использование XML-файла (я использовал бы файл простого текста). Но более используемая тактика должна просто протестировать предельные ситуации, как использование, в Вашем случае, входном значении-360, 360,-361, 361 и 0.

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

Не уверенный, насколько сложный Ваш код, если он принимает целое число и делит его на 8 или 16 направлений на компасе, это - вероятно, несколько строк кода да?

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

В этом конкретном случае я подал бы его каждое число в порядке от-360 до +360 и распечатал бы число и результат (к текстовому файлу в формате, который может быть скомпилирован в другую программу как заголовочный файл). Визуально осмотрите это изменения направления в желаемом входе. Это должно быть легко визуально осмотреть и проверить. Теперь у Вас есть таблица исходных данных и допустимых выводов. Затем имейте программу, случайным образом выбирают из допустимых исходных данных, подают его в Ваш код под тестом и видят, что правильный ответ выходит. Сделайте несколько сотен из этих случайных тестов. В какой-то момент необходимо проверить это числа, меньше чем-360 или больше, чем +360 обрабатываются на требования, или отсечение или модуляция, которую я принимаю.

Таким образом, я взял программное обеспечение, тестирующее текст ссылки класса и в основном что Вы хотите, должен определить класс исходных данных.. все вещественные числа? все целые числа, только положительные, только отрицательные, и т.д. Тогда группируют выходные действия. 360 исключительно отличающиеся от 359, или сделайте они в значительной степени заканчивают тем, что делали то же самое к приложению. Однажды там делают комбинацию исходных данных к выводам.

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

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

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

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

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

Psuedocode:

array colors = { red, orange, yellow, green, blue, brown, black, white }
for north = -360 to 361
    for bearing = -361 to 361
        theColor = colors[dirFunction(north, bearing)] // dirFunction is the one being tested
        setColor (theColor)
        drawLine (centerX, centerY,
                  centerX + (cos(north + bearing) * radius),
                  centerY + (sin(north + bearing) * radius))
        Verify Resulting Circle against rotated reference diagram.

, Когда Север = 0, Вы получите 8-цветную круговую диаграмму. Поскольку север варьируется + или - круговая диаграмма будет выглядеть одинаково, но повернутый вокруг этого много градусов. Тестовая проверка является простым вопросом проверки что (a) изображение является правильно повернутой круговой диаграммой и (b) нет никаких зеленых пятен в оранжевой области, и т.д.

, Эта техника, между прочим, является изменением на самом большом средстве отладки в мире: Имейте компьютер, привлекают Вас изображение того, какой =IT = думает, что это делает. (Слишком часто разработчики тратят впустую часы, преследуя то, что они думают, что компьютер делает, только чтобы найти, что он делает что-то совершенно другое.)