Платформы Поблочного тестирования - Каковы основные характеристики

Вот некоторые вещи, которые я ищу

• Speed. Не все фреймворки (и участники тестирования) одинаковы. Если ваши модульные тесты отстают, ваше продуктивное время будет потрачено зря.
• Asserts. Их должно быть много, чтобы обеспечить множество сценариев. Вам нравятся исключения, перехватываемые, например, с помощью атрибута или Assert.Throws ? Могут ли утверждения выполнять числовые сравнения с заданным допуском?
• Разное. Полезные вещи, которые есть в некоторых фреймворках, такие как, например, строковые тесты или возможность читать тестовые данные в формате XML.

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

По этой причине я предпочитаю nUnit, потому что для него есть предварительно созданные задачи сборки в CruiseControl, который я выбрал сервер сборки. Это не означает, что вы не можете подключить какие-либо другие среды тестирования к CC, nUnit просто удобен в использовании.

Что касается доступных функций, MSTest имеет несколько действительно хороших надстроек, когда вы запускаете его с по фантастической цене Visual Studio Team System с TFS в бэкэнде.

Сказав все это, на самом деле нет такой большой разницы в функциональности отдельных сред тестирования (у меня есть опыт работы с xUnit, nUnit и MSTest) - все они позволяют определять модульные тесты и сообщать о том, как много прошло и сколько не удалось. У всех есть какой-то графический интерфейс,

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

Однако, если вам нужен совет по выбору , Я предлагаю вам прочитать на странице XUnit «почему мы создали xunit» , которая указывает на некоторые проблемы, связанные с фреймворками модульного тестирования.

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

Конечно, выбор фреймворка BDD - это совсем другое дело.

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

Я собираюсь использовать Ruby в качестве примера, но это применимо к любой среде. (И, кстати, вы не ограничены фреймворками C # для тестирования приложений .NET, вы можете использовать любой язык .NET, одним из которых, конечно же, является Ruby, а также Python, Scheme, F #,…)

Это test / unit (порт ранней версии JUnit) с Mocha для имитации.

def test_state
  assert_equal 2, 1+1
end

def test_exception
  assert_raises(NoMethodError) { [].not_a_method }
end

def test_behavior
  o = Object.new
  o.expects(:ping).with(:pong)
  o.ping(:pong)
end

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

И это Ожидания, которые AFAIK - единственная структура, которая делает это правильно. (На самом деле, он был создан специально для единообразных утверждений.) К сожалению, он больше не поддерживается и не поддерживается, поскольку автор больше не выполняет никакой работы с Ruby.

expect 2 do
  1+1
end

expect NoMethodError do
  [].not_a_method
end

expect Object.new.to.receive(:ping).with(:pong) do |o|
  o.ping(:pong)
end

Обратите внимание, что утверждения всегда выглядят одинаково, и оба утверждения и тестовый код всегда находятся в одном месте.

Однако новые фреймворки, такие как xUnit.Net и Mockito, определенно приближаются.

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

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

Вот пример (в RSpec, который, конечно, также можно использовать в .NET, на этот раз):

describe Array do
  it 'should be empty' do
    Array.new.should be_empty
  end
end

Это просто глупо. Любой разработчик, которому нужно название теста, чтобы понять, что делает этот тест, должен серьезно пересмотреть свой выбор карьеры. Также возникают все те же проблемы с комментариями: что, если кто-то изменит тест, но забудет изменить имя? Теперь название не только бесполезное, но и вводящее в заблуждение! Это намного лучше:

describe Array do
  it do
    Array.new.should be_empty
  end
end

У RSpec есть еще один изящный трюк в рукаве: он автоматически создаст экземпляр класса, который вы тестируете для вас, так что вам не нужно говорить ClassUnderTest.new.should снова и снова, вы можете просто сказать следует :

describe Array do
  it { should be_empty }
end

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

Array
 - should be empty