Как поблочное тестирование лучше, чем просто тестирование всего вывода Вашего приложения в целом?
Вы можете проверить код ascii 1-го символа:
select *
from HR.Employees
where ascii(substring(name, 1, 1)) between ascii('a') and ascii('z')
вы также можете использовать функцию left(name, 1) вместо substring(name, 1, 1).
15 ответов
То, что вы описываете, - это интеграционное тестирование. Интеграционное тестирование не скажет вам, какая часть вашего массивного приложения работает некорректно, когда ваши результаты больше не верны.
Преимущество модульного тестирования заключается в том, что вы можете написать тест для каждого бизнес-предположения или шага алгоритма, который вы нужна ваша программа для выполнения. Когда кто-то добавляет или изменяет код в вашем приложении, вы сразу же точно знаете, какой шаг, какая часть и, возможно, какая строка кода нарушена при появлении ошибки. Экономия времени на обслуживании только по этой причине делает его стоящим, но есть еще одно большее преимущество в том, что нельзя вводить ошибки регрессии (если ваши тесты запускаются автоматически при сборке программного обеспечения). Если вы исправите ошибку,
Начнем с регрессионного тестирования. Как только вы найдете ошибку, напишите небольшой тест, который демонстрирует ошибку, исправьте ее и убедитесь, что тест прошел успешно. В будущем вы можете запускать этот тест перед каждым выпуском, чтобы убедиться, что ошибка не была повторно введена.
Почему это делается на уровне блока, а не на уровне всей программы? Скорость. В хорошем коде гораздо быстрее изолировать небольшой модуль и написать крошечный тест, чем довести сложную программу до точки ошибки.
Тестеры обычно тестируют сквозную функциональность. Очевидно, это предназначено для использования в пользовательских сценариях и имеет невероятную ценность.
Модульные тесты служат для другой функциональности. Разработчики проверяют правильность работы написанных компонентов при отсутствии других функций или в сочетании с другими функциями. Это предлагает диапазон значений, включая
- Предоставляет не игнорируемую документацию
- Способность изолировать ошибки в определенных компонентах
- Проверять инварианты в коде
- Обеспечивать быструю, немедленную обратную связь с изменениями в кодовая база.
Все еще существует необходимость в определенном уровне ручного тестирования, но модульное тестирование используется для уменьшения количества дефектов, которые делают это на этом этапе. Модульное тестирование тестирует самые маленькие части системы, и если все они работают, шансы приложения в целом работать правильно значительно повышаются.
Это также помогает при добавлении новых функций, поскольку регрессионное тестирование может быть выполнено быстро и автоматически.
Для достаточно сложного приложения тестирование всей продукции в целом может не охватывать достаточно различных возможностей. Например, любое приложение имеет огромное количество различных путей кода, которые могут следовать в зависимости от ввода. В типичном тестировании может быть много частей вашего кода, которые просто никогда не встречаются, потому что они используются только при определенных обстоятельствах, поэтому вы не можете быть уверены, что любой код, который не выполняется в вашей тестовой ситуации, действительно работает. Кроме того, ошибки в одном разделе кода могут быть замаскированы в большинстве случаев чем-то другим в другом разделе кода, поэтому вы можете никогда не обнаружить некоторые ошибки.
Лучше тестировать каждую функцию или класс отдельно. Таким образом, тест легче написать, потому что вы тестируете только небольшой фрагмент кода. Это'
Сделайте себе одолжение и сначала попробуйте юнит-тестирование. Я сам был скептиком, пока не понял, насколько чертовски полезны / мощные юнит-тесты. Если вы подумаете об этом, они действительно не могут добавить к вашей рабочей нагрузке. Они созданы для того, чтобы обеспечить вам душевное спокойствие и позволить вам продолжать расширять ваше приложение, обеспечивая при этом надежность вашего кода. Вы получаете немедленную обратную связь относительно того, когда вы, возможно, что-то сломали, и это что-то необычайно ценное.
На вопрос о том, зачем тестировать небольшие участки кода, подумайте: предположим, что ваше гигантское приложение использует классную схему шифрования XOR, которую вы написали, и в конечном итоге руководство продукта изменит требования к тому, как вы генерируете эти зашифрованные строки. Итак, вы говорите: «Черт, я написал процедуру шифрования, поэтому я Пойдем дальше и внесем изменения. Это займет у меня 15 минут, и мы все пойдем домой и устроим вечеринку. «Ну, возможно, вы внесли ошибку во время этого процесса. Но подождите !!! Ваш удобный метод TestXOREncryption () немедленно сообщает вам, что ожидаемый Выходные данные не совпадали с входными данными. Бинго, поэтому вы заранее разбили свои модульные тесты на маленькие «единицы» для проверки, потому что в вашем гигантском приложении вы бы не поняли это так быстро.
Также как только вы начнете думать о регулярном написании модульных тестов, вы поймете, что, хотя вы изначально оплачиваете первоначальные затраты по времени, вы вернетесь к этому в 10 раз позже в цикле разработки, когда сможете быстро определить области в вашем коде, которые привели к проблемам.
Нет волшебной палочки с юнит-тестами, потому что ваша способность выявлять проблемы так же хороша, как и тесты, которые вы пишете. Это сводится к созданию лучшего продукта и избавлению от стресса и головных болей. =)
Чем раньше вы поймаете ошибки, тем дешевле их исправить. Ошибка, обнаруженная кодовым тестером во время модульного тестирования, довольно дешева (просто исправьте чертову вещь).
Ошибка, обнаруженная во время системного или интеграционного тестирования, стоит дороже, поскольку вы должны исправить ее и перезапустить цикл тестирования.
A Обнаруженная вашим клиентом ошибка будет стоить дорого: перекодирование, повторное тестирование, переупаковка и так далее. Это также может привести к болезненной загрузочной печати на вашем derriere, когда вы сообщаете руководству, что вы не уловили его во время модульного тестирования, потому что вы ничего не делали, думая, что системные тестеры найдут все проблемы: -)
Как много денег стоило бы GM вспомнить 10000 автомобилей, потому что каталитический нейтрализатор не не работают должным образом?
Теперь подумайте, сколько им будет стоить, если они обнаружат, что сразу после того, как эти преобразователи были им доставлены, но до их посадили в эти 10 000 автомобилей.
Я думаю, последний вариант окажется немного дешевле.
Это одна из причин, почему разработка на основе тестирования и непрерывная интеграция (иногда) - это хорошая вещь - тестирование проводится постоянно.
Кроме того, модульные тесты не проверяйте, что программа работает как единое целое, просто каждый бит работает как положено. Это часто много больше, чем тесты более высокого уровня.
Одна из причин, почему разработка через тестирование и непрерывная интеграция (иногда) - это хорошая вещь - тестирование проводится постоянно.Кроме того, модульные тесты не проверяют, что программа работает как единое целое, просто каждый маленький кусочек выполняет как ожидалось. Это часто много больше, чем тесты более высокого уровня.
Одна из причин, почему разработка через тестирование и непрерывная интеграция (иногда) - это хорошая вещь - тестирование проводится постоянно.Кроме того, модульные тесты не проверяют, что программа работает как единое целое, просто каждый маленький кусочек выполняет как ожидалось. Это часто много больше, чем тесты более высокого уровня.
К этому сложному вопросу нужно подходить, потому что он ставит под сомнение что-то такого огромного размера. Вот мой короткий ответ, однако:
Test Driven Development (или TDD) стремится доказать , что каждая логическая единица приложения (или блок кода) функционирует именно так, как и должна. Делая тесты настолько автоматизированными, насколько это возможно, ради производительности, как это может быть вредным?
Тестируя каждый логический фрагмент кода, вы можете доверить использование кода некоторой иерархии. Скажем, я создаю приложение, основанное на поточно-ориентированной реализации стека. Разве нельзя гарантировать, что стек будет работать на каждом этапе, прежде чем я его построю?
Ключ в том, что если что-то в приложении целом сломается, то есть просто смотрит на общий результат / результат, откуда ты знаешь, откуда он взялся? Ну, отладка, конечно! Что возвращает вас туда, откуда вы начали. TDD позволяет вам, к счастью, обойти этот самый болезненный этап развития.
Из моего опыта:
- Интеграция и функциональное тестирование, как правило, более показательным для общего качества системы, чем костюм модульного тестирования.
- Тестирование высокого уровня (функциональное, приемочное) является инструментом обеспечения качества.
- Модульное тестирование является инструментом разработки . Особенно в контексте TDD, где модульное тестирование становится скорее реализацией проекта, а не гарантией качества.
- В результате лучшего проектирования качество всей системы улучшается (косвенно).
- Прохождение модульного теста Пакет предназначен для обеспечения того, чтобы один компонент соответствовал намерениям разработчика (правильность). Приемочный тест - это уровень, который охватывает достоверность системы (т. Е. Система выполняет то, что пользователь хочет, чтобы она делала).
Резюме:
- Сначала модульный тест предназначен как инструмент разработки, а затем как инструмент QA.
- Приемочный тест подразумевается как инструмент обеспечения качества.
Вероятно, единственная самая большая проблема с программным обеспечением - это просто количество взаимодействующих вещей, и наиболее полезный метод заключается в сокращении количества вещей, которые необходимо учитывать.
Например, использование языки более высокого уровня, а не низкоуровневые, повышают производительность, поскольку одна строка - это отдельная вещь, а возможность писать программу в несколько строк уменьшает количество вещей.
Процедурное программирование возникло как попытка уменьшить сложность путем делая возможным рассматривать функцию как вещь. Однако, чтобы сделать это, мы должны иметь возможность думать о том, что функция делает согласованным образом и с уверенностью, что мы правы. (Объектно-ориентированное программирование делает аналогичную вещь в более широком масштабе.)
Есть несколько способов сделать это. Проектирование по контракту - это способ точно определить, что делает функция. Использование параметров функции вместо глобальных переменных для вызова функции и получения результатов снижает сложность функции.
Модульное тестирование - это один из способов убедиться, что функция выполняет то, что должна. Обычно можно протестировать весь код функции, а иногда и все пути выполнения. Это способ определить, работает ли функция так, как должна, или нет. Если функция работает, мы можем думать о ней как об одной вещи, а не как о нескольких вещах, которые мы должны отслеживать.
Она служит другим целям. Модульные тесты, как правило, быстро выполняются, и поэтому могут быстро обнаруживать ошибки, когда их легко исправить. Если разработчики удостоверится, что функция прошла тесты перед тем, как ее зарегистрировать, тогда тесты являются формой документирования того, что делает функция, которая гарантированно корректна. Акт создания тестов заставляет тестировщика задуматься о том, что должна делать функция. После этого, кто бы ни хотел изменения, он может посмотреть на тесты, чтобы понять, правильно ли он понял.
В отличие от этого, более масштабные тесты не являются исчерпывающими и поэтому могут легко пропустить множество ошибок. Они плохо в локализации ошибок. Обычно они выполняются с довольно большими интервалами, поэтому они могут обнаружить ошибку через некоторое время после ее появления. Они определяют части общего пользовательского опыта, но не дают оснований рассуждать о какой-либо части системы. Им не следует пренебрегать, но они не могут заменить модульные тесты.
После этого, кто бы ни хотел изменения, он может посмотреть на тесты, чтобы понять, правильно ли он понял.В отличие от этого, более масштабные тесты не являются исчерпывающими и поэтому могут легко пропустить множество ошибок. Они плохо в локализации ошибок. Обычно они выполняются с довольно большими интервалами, поэтому они могут обнаружить ошибку через некоторое время после ее появления. Они определяют части общего пользовательского опыта, но не дают оснований рассуждать о какой-либо части системы. Им не следует пренебрегать, но они не могут заменить модульные тесты.
После этого, кто бы ни хотел изменения, он может посмотреть на тесты, чтобы понять, правильно ли он понял.В отличие от этого, более масштабные тесты не являются исчерпывающими и поэтому могут легко пропустить множество ошибок. Они плохо в локализации ошибок. Обычно они выполняются с довольно большими интервалами, поэтому они могут обнаружить ошибку через некоторое время после ее появления. Они определяют части общего пользовательского опыта, но не дают оснований рассуждать о какой-либо части системы. Им не следует пренебрегать, но они не могут заменить модульные тесты.
поэтому они могут обнаружить ошибку через некоторое время после ее появления. Они определяют части общего пользовательского опыта, но не дают оснований рассуждать о какой-либо части системы. Им не следует пренебрегать, но они не могут заменить модульные тесты. поэтому они могут обнаружить ошибку через некоторое время после ее появления. Они определяют части общего пользовательского опыта, но не дают оснований рассуждать о какой-либо части системы. Им не следует пренебрегать, но они не могут заменить модульные тесты.Тестируемое программное обеспечение - это система. Когда вы тестируете его в целом, вы тестируете черный ящик, поскольку вы в первую очередь имеете дело с входами и выходами. Тестирование черного ящика прекрасно, когда у вас нет возможности проникнуть внутрь системы.
Но поскольку вы это делаете обычно, вы создаете множество модульных тестов, которые фактически тестируют вашу систему как белый ящик. Вы можете разрезать систему разными способами и организовывать тесты в зависимости от внутренней структуры системы. Тестирование белого ящика предоставляет вам гораздо больше способов тестирования и анализа систем. Он явно дополняет тестирование черного ящика и не должен рассматриваться как альтернативная или конкурирующая методология.
Модульное тестирование поможет вам более четко определить источник вашей ошибки, а сообщит вам, что у вас возникла проблема ранее . И то, и другое полезно иметь, но они разные, и у модульного тестирования есть свои преимущества.
Как утверждали другие, длина цикла обратной связи и изоляция проблемы от конкретного компонента являются ключевыми преимуществами модульных тестов.
Еще одним способом их дополнения к функциональным тестам является как отслеживается покрытие в некоторых организациях:
- Модульные тесты покрытия кода
- Функциональные тесты покрытия требований
Функциональные тесты могут пропускать функции, которые были реализованы, но не указаны в спецификации.
Будучи основанными на коде, модульные тесты могут упускать из виду, что определенная функция не была реализована, и именно здесь на помощь приходит анализ покрытия функционального тестирования на основе требований.
Последний пункт: есть некоторые вещи, которые проще / быстрее тестировать на уровне устройства, особенно в случае ошибок.
Очень просто: модульные тесты легче писать, поскольку вы тестируете только функциональность одного метода. А ошибки исправлять легче, поскольку вы точно знаете, какой метод не работает.
Но, как указали другие респонденты, модульные тесты - это не самое главное в тестировании. Это лишь малая часть уравнения.
Согласен с большинством ответов. Давайте углубимся в тему скорости. Вот некоторые действительные числа:
Модульный тест дает 1 или 2 минуты из свежая компиляция. Как истинные модульные тесты (нет взаимодействия с внешними такие системы, как dbs) они могут покрыть много логики очень быстро.
Автоматическое функциональное испытание дает результат 1 или 2 часа . Они работают на упрощенной платформе, но иногда охватывают несколько систем и базу данных, что действительно убивает скорость.
Автоматический интеграционный тест дает результаты один раз в день . Они тренируют полноценный прием пищи, но настолько тяжелы и медленны, что мы можем выполнять их только один раз в день, и это занимает несколько часов.
Результаты ручной регрессии приходят через несколько недель . Мы передаем материалы тестерам несколько раз в день, но в лучшем случае ваши изменения не регрессируют в течение недели или двух.
Я хочу узнать, что я сломал, за 1 или 2 минуты, а не за несколько недель, даже не за несколько часов. Отсюда и 10-кратная рентабельность инвестиций в модульные тесты, о которых говорят.