Приемочные испытания против примеров модульных испытаний - PullRequest
4 голосов
/ 13 июля 2011

ОК, поэтому я пытался посмотреть информацию о тестировании, о разных библиотеках тестирования, а что нет, и т. Д.

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

Но похоже, что каждая статья о типах тестов заканчивается чем-то вроде: «на практике это может быть труднопосмотри какая разница на самом деле ".Я нахожу странным, что люди кажутся настолько проповедническими, что вам нужно как тестировать, чтобы даже достичь какого-либо полного охвата кода, и в то же время не иметь никакой хорошей информации / примеров того, как каждый из них может выглядеть.

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

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

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

пример для .net был бы отличным, но, поскольку большинство тестируемых фреймворков cucumber (gherkin) / rspec и т. Д. Предназначены для того, чтобы быть достаточно читабельными, любой пример должен быть хорошим.

Ответы [ 2 ]

3 голосов
/ 14 июля 2011

См. Видео о различных типах тестирования .Различные типы методов испытаний сравниваются с таблицей.

3 голосов
/ 13 июля 2011

"in practice it could be hard to see what the difference actually is":

Я могу дать только общие рекомендации по тестированию.Большие программные проекты обычно предполагают некую иерархию.

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

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

Иерархический подход оптимизирует усилия по тестированию.

...