Что такое модульное тестирование и как вы это делаете?

Ответ 1

Тестирование модулей включает разбиение вашей программы на части и подвержение каждой части серии тестов.

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

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

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

Ответ 2

Что такое модульное тестирование?

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

Результат теста может быть таким же простым, как вывод консоли, в " зеленый свет" в графическом интерфейсе, таком как NUnit или другая языковая среда.

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

Как вы выполняете модульные тесты?

Представьте себе очень простую функцию, которую вы хотели бы протестировать:

int CombineNumbers(int a, int b) {
    return a+b;
}

Код unit test будет выглядеть примерно так:

void TestCombineNumbers() {
    Assert.IsEqual(CombineNumbers(5, 10), 15); // Assert is an object that is part of your test framework
    Assert.IsEqual(CombineNumbers(1000, -100), 900);
}

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

Теперь представьте себе, что другой разработчик приходит и меняет функцию CombineNumbers() для производительности или по какой-то другой причине:

int CombineNumbers(int a, int b) {
    return a * b;
}

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

Когда вы должны выполнять модульные тесты?

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

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

Ответ 3

Что...

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

"Единица" в этом смысле является наименьшей атомной составляющей кода, которая имеет смысл тестировать, как правило, метод некоторого класса, например. Часть этого процесса заключается в создании объектов-заглушек (или "mocks" ), которые позволяют вам работать с устройством как независимый объект.

Как...

Практически всегда процесс модульного тестирования встроен в IDE (или через расширения), так что он выполняет тесты с каждым компилятором. Существует ряд рамок для оказания помощи в создании модульных тестов (и, действительно, имитации объектов), часто называемых fooUnit (cf.jUnit, xUnit, nUnit). Эти рамки обеспечивают формализованный способ создания тестов.

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

Когда...

Почти всегда. Очень маленькие проекты с отбросами могут не стоить того, но только если вы уверены, что они действительно выбрасывают деньги. Теоретически каждая объектно-ориентированная программа является проверяемой единицей, но некоторые конструктивные патты делают это трудным. Известно, что одноэлементный шаблон является проблематичным, в котором конверсионные схемы вложений, основанные на зависимости, очень ориентированы на единичное тестирование.

Ответ 4

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

http://www.nunit.org/index.php?p=quickStart&r=2.5

Можно ли все проверить? Обычно, если он что-то вычисляет, то да. Кодирование UI - это еще одна проблема, с которой приходится иметь дело, поскольку имитация пользователей, нажимая кнопки, сложна.

Что вы должны проверить? Я склонен писать тесты вокруг того, что, как я знаю, будет сложным. Сложные переходы состояния, критически важные вычисления, что-то вроде этого. Вообще я не слишком беспокоюсь о тестировании базовых материалов ввода/вывода, хотя пуристы, без сомнения, скажут, что я ошибаюсь на этом фронте, и все должно быть проверено. Как и многие другие, нет правильного ответа!

Ответ 5

Что такое unittesting? Трудно определить. На техническом уровне вы создаете функции, которые вызывают функции в вашей кодовой базе и проверяют результаты. В принципе, вы получаете кучу вещей, таких как "assert (5 + 3) == 8", еще сложнее (как в DataLayer (MockDatabase()). GetUser(). Name == "Dilbert" ). На уровне инструментального уровня вы добавляете автоматическую, зависящую от проекта проверку, все ли работает, как будто вы предполагали, что все работает. Это очень, очень полезно, если вы рефакторинг и реализуете сложные алгоритмы. Результатом, как правило, является куча документации и намного меньше ошибок, потому что поведение кода закреплено.

Я создаю тестовые примеры для всех краевых случаев и запускаю их подобно работам коллектора мусора. Пока я реализую класс, я запускаю только те тесты, которые включают класс. Как только я закончил работу над этим классом, я запускаю все unittests, чтобы проверить, все ли работает.

Вы должны проверить как можно больше, если тестовый код достаточно прост, чтобы оставаться непроверенным. Учитывая это, нет, не все можно легко проверить. Подумайте о интерфейсах пользователя. Подумайте, водитель для космического челнока или ядерной бомбы (по крайней мере, не с чистыми JUnit-тестами;)). Тем не менее, много и много кода можно проверить. Структуры данных. Алгоритмы. Большинство классов ApplicationLogic. Так что протестируйте его!

НТН. tetha

Ответ 6

Что именно тестирует устройство? Это встроенный в код или выполняемый как отдельный программы? Или что-то еще?

Из MSDN: Основная цель модульного тестирования - взять в приложении наименьшую часть тестируемого программного обеспечения, изолировать ее от остальной части кода и определить, будет ли он вести себя точно так, как вы ожидаете.

По существу, вы пишете небольшие биты кода для проверки отдельных битов вашего кода. В мире .net вы будете запускать эти маленькие биты кода, используя что-то вроде NUnit или MBunit или даже встроенных инструментов тестирования в visual studio. В Java вы можете использовать JUnit. По сути, тестовые бегуны будут строить ваш проект, загружать и выполнять модульные тесты, а затем сообщать вам, проходят ли они или не выполняются.

Как вы это делаете?

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

Когда это должно быть сделано? Могут ли времена или проекты не делать этого? Является все единицы измерения?

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

Тестирование модулей - это серьезная тема, и вы можете полностью понять, как она может вам лучше всего помочь. Я бы рекомендовал получить книгу по модульному тестированию, например " Test Driven Development by Example", который даст вам хорошее представление о концепциях и способах их применения к вашему коду.

Ответ 7

В части "Как это сделать":

Я думаю, что введение в ScalaTest действительно помогает иллюстрировать разные стили модульных тестов.

В разделе "Когда это сделать":

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

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