Модульное тестирование: вопросы для начинающих - PullRequest
12 голосов
/ 23 января 2009

Я, наконец, начинаю с юнит-тестирования, зная, что я должен сделать это некоторое время, но у меня есть несколько вопросов:

  • Должен или не должен перепроверять родителей занятия при тестировании детей, если методы не были перезаписаны?
  • Концептуально, как вы тестируете отправили часть формы? я использую PHP. ( Редактировать : причина, по которой я спрашиваю это, заключается в том, что у меня есть класс формы высокого уровня, который генерирует форму, проверяет ее, фильтрует ее и генерирует все сообщения об ошибках, принимая массив JSON-подобных в качестве входных данных и делегируя к множеству небольших классов. Однако я не могу проверить ошибки и т. д., не отправив форму. Редактировать : Этот выглядит так, как будто это может быть ответ.)
  • Если у вас есть необязательный параметр в метод, если вы пишете тест для и когда они присутствуют, и когда они не?
  • Должно ли юнит-тестирование быть каким-либо образом в сочетании с тестированием выполнения кода время или они должны оставаться полностью отдельно
  • Есть ли веская причина не запускать Ваш полный набор тестов каждый раз?
  • Просто так я получаю свою терминологию правильно, к чему относится блок в блоке тестирование ссылаетесь? Класс существо тестирование? Метод? Параметр? Что-то еще?

Ответы [ 4 ]

9 голосов
/ 23 января 2009
  • Тест родителя, тест ребенка; если дочерний элемент не переопределяет родительский метод, нет необходимости повторно его тестировать.
  • Я не уверен, что понимаю второй. Вы можете использовать Selenium для автоматизации тестирования формы. Это то, что вы имеете в виду?
  • Тесты должны включать «счастливый путь» и все крайние случаи. Если у вас есть необязательный параметр, напишите тесты, чтобы показать правильную работу со значением, присутствующим и отсутствующим.
  • Модульные тесты, интеграционные тесты, приемочные тесты, нагрузочные тесты - разные идеи, которые могут иметь некоторое совпадение.
  • Держу пари, что есть веские причины, но если вы делаете автоматические сборки, которые автоматически запускают набор тестов, почему бы вам не запустить их? Возможно, на ум приходят долгие времена, но это единственная причина, о которой я могу думать. Ценность заключается в том, что все они продолжают проходить, и внесенные вами изменения ничего не сломали.
  • Под модульным тестом для меня понимается класс, который вы тестируете, который может иметь несколько методов. Я ассоциирую их с классами, а не с формами. Формы означают тестирование пользовательского интерфейса и интеграцию для меня.
6 голосов
/ 23 января 2009

(не совсем в том же порядке, что и ваши вопросы)

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

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

  • Из Википедии: «Единица - это самая маленькая тестируемая часть приложения».

2 голосов
/ 23 января 2009

Я отвечу тем, что могу.

Должен ли я проверять родительские классы при тестировании детей, если не было перезаписано ни одного метода?

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

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

Да, тестируйте все, что вызывает изменение в поведении.

Следует ли каким-либо образом комбинировать модульное тестирование со временем выполнения кода или они должны оставаться полностью раздельными?

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

Есть ли веская причина не запускать ваш полный набор тестов каждый раз?

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

Просто так я правильно понимаю свою терминологию, к чему относится модуль в модульном тестировании? Класс проверяется? Метод? Параметр? Что-то еще?

«Единица» относится к тестируемому методу. Это самая маленькая единица, на которую имеет смысл разбивать программное обеспечение. Метод класса A может использовать класс B, но любой тест, который вы пишете для этого метода, не должен волновать. Просто протестируйте этот метод.

2 голосов
/ 23 января 2009

Ответы на вопросы по порядку:

  • Если родительские классы уже проверены, то избегайте дублирования и просто проверяйте новые аспекты ребенка или любые аспекты, которые ребенок изменил.
  • Не уверен - сделали очень мало PHP.
  • Да => проверить все аспекты метода.
  • У вас могут быть некоторые модульные тесты, которые тестируют производительность, но они будут ориентированы на производительность, тогда как другие могут быть сосредоточены на тестировании функциональности. Не смешивайте оба в одном тесте.
  • В идеале вы должны запускать их каждый раз и часто. Иногда, если время выполнения очень велико, вы можете подумать о том, чтобы реорганизовать их в более мелкие комплекты, а затем выполнять исполняемые комплекты только тогда, когда что-то меняется, - но все равно периодически делать все.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...