Чем “единица” должна быть когда поблочное тестирование?
Существует несколько различий между временными таблицами (#tmp) и переменными таблиц (@tmp), хотя использование tempdb не является одним из них, как указано в ссылке MSDN ниже.
Как правило, для небольших и средних объемов данных и простых сценариев использования следует использовать табличные переменные. (Это слишком широкое руководство с, конечно, множеством исключений - см. Ниже и в следующих статьях.)
Некоторые моменты, которые следует учитывать при выборе между ними:
-
Временные таблицы являются реальными таблицами, так что вы можете делать такие вещи, как CREATE INDEXes и т. д. Если у вас есть большие объемы данных, доступ к которым по индексу будет быстрее, тогда временные таблицы - хороший вариант.
-
Табличные переменные могут иметь индексы с помощью ограничений PRIMARY KEY или UNIQUE. (Если вам нужен неуникальный индекс, просто включите столбец первичного ключа в качестве последнего столбца в ограничении уникальности. Если у вас нет уникального столбца, вы можете использовать столбец идентификаторов.) В SQL 2014 есть не уникальные индексы тоже .
-
Табличные переменные не участвуют в транзакциях, а
SELECTнеявно связаны сNOLOCK. Поведение транзакции может быть очень полезным, например, если вы хотите выполнить ROLLBACK в середине процедуры, тогда табличные переменные, заполненные во время этой транзакции, будут по-прежнему заполнены! -
Временные таблицы могут привести к хранимым процедурам перекомпилируется, возможно часто. Табличные переменные не будут.
-
Вы можете создать временную таблицу, используя SELECT INTO, которая может быть быстрее написана (хорошо для специальных запросов) и может позволить вам иметь дело с изменением типов данных с течением времени, так как вам не нужно определять ваша временная структура таблицы заранее.
-
Вы можете передавать табличные переменные из функций, что значительно упрощает инкапсуляцию и повторное использование логики (например, создание функции для разбиения строки на таблицу значений на некотором произвольном разделителе). [тысяча сто тридцать одна]
-
Использование табличных переменных в пользовательских функциях позволяет более широко использовать эти функции (подробнее см. Документацию CREATE FUNCTION). Если вы пишете функцию, вы должны использовать табличные переменные над временными таблицами, если нет острой необходимости.
-
Табличные переменные и временные таблицы хранятся в базе данных tempdb. Но для табличных переменных (с 2005 года) по умолчанию используется сопоставление текущей базы данных по сравнению с временными таблицами, которые принимают сопоставление по умолчанию для базы данных tempdb ( ref ). Это означает, что вы должны знать о проблемах сопоставления, если вы используете временные таблицы и ваша база данных сопоставления отличается от базы данных tempdb, что создает проблемы, если вы хотите сравнить данные в временной таблице с данными в вашей базе данных.
-
Глобальные временные таблицы (## tmp) - это еще один тип временных таблиц, доступных для всех сеансов и пользователей.
Некоторое дальнейшее чтение:
-
Великий ответ Мартина Смита на dba.stackexchange.com
-
Часто задаваемые вопросы MSDN о различиях между ними: https://support.microsoft.com/en-gb/kb/305977
-
MDSN статья в блоге: http://blogs.msdn.com/sqlserverstorageengine/archive/2008/03/30/sql-server-table-variable-vs-local-teilitary-table.aspx
-
Статья: http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1267047,00.html#
-
Неожиданное поведение и влияние на производительность временных таблиц и временных переменных: Пол Уайт на SQLblog.com
9 ответов
Может показаться тривиальным цитировать Википедию , но я думаю, что в данном случае это очень лаконично и точно:
Единица измерения - это самая маленькая тестируемая часть приложения.
Кажется, это согласуется с комментарием в вашем вопросе о том, что модуль - это «наименьший фрагмент кода, который можно с пользой протестировать». Другими словами, сделайте модуль настолько маленьким, насколько это возможно , чтобы он по-прежнему имел смысл для разработчика / тестировщика сам по себе .
Часто вам нужно тестировать части проекта изолированно, и затем проверьте, как они взаимодействуют в комбинации. Наличие различных уровней (уровней) модульного тестирования часто бывает разумным, поскольку это помогает убедиться, что ваш код работает должным образом на всех уровнях, от отдельных функций до целых автономных задач. Я лично не считаю, что тестировать отдельные функции неправильно или даже бесполезно, пока они сами по себе делают что-то полезное, что часто бывает.
Честно говоря, нет определенного или строгое определение «модуля» в «модульном тестировании», именно поэтому используется расплывчатый термин «модуль»! Узнать, что и на каком уровне нужно тестировать, - это вопрос опыта и довольно часто просто проб и ошибок. Это может показаться немного неудовлетворительным ответом, но я считаю, что это здравое правило, которому нужно следовать.
именно поэтому используется расплывчатый термин «единица»! Узнать, что и на каком уровне нужно тестировать, - это вопрос опыта и довольно часто просто проб и ошибок. Это может показаться немного неудовлетворительным ответом, но я считаю, что это здравое правило, которому нужно следовать. именно поэтому используется расплывчатый термин «единица»! Узнать, что и на каком уровне нужно тестировать, - это вопрос опыта и довольно часто просто проб и ошибок. Это может показаться немного неудовлетворительным ответом, но я считаю, что это здравое правило, которому нужно следовать.«Единица» должна быть одной атомарной единицей для вашего определения . То есть, что именно определяет «модуль» для модульного тестирования, довольно субъективно; он может довольно сильно зависеть от того, какова ваша архитектура и как ваше приложение решает разбить функциональные блоки. Я говорю о том, что не существует четко определенной «единицы», кроме той, которую вы определяете. «Единицей» может быть отдельный метод, имеющий единственный побочный эффект, или связанный набор методов, которые вместе определяют единый согласованный набор функций.
Здесь довольно важна рациональность; вполне возможно написать модульные тесты для каждого метода доступа каждого имеющегося у вас класса; однако это явно перебор. Точно так же Возможно, но глупо определять все ваше приложение как единое целое и ожидать, что для его тестирования будет один тест.
Как правило, вам нужен «модуль» для тестирования, чтобы описать один четко определенный, четко обособленный фрагмент функциональности. На каждом уровне просмотра вашего приложения вы должны видеть четкие «атомы» функциональности (если ваш дизайн хорош); они могут быть такими же простыми, как «получить запись из базы данных» для низкоуровневого представления, и столь же сложными, как «создать, отредактировать и удалить пользователя» для высокоуровневого представления. Они также не исключают друг друга; вы можете легко использовать оба в качестве модульных тестов.
Здесь нужно принять во внимание то, что модуль, который вы хотите протестировать, - это тот модуль, который имеет смысл. Вы хотите, чтобы модульное тестирование проверяло и проверяло функциональность; Итак, модульное тестирование - это то, что вы определяете как функциональность. Что такое единица функциональности? Это зависит от вашей индивидуальной ситуации.
Я всегда тестировал на уровне функций, и это отлично работало. Для меня важно то, что модульное тестирование проверяет контракт между двумя частями кода. Модульный тест просто действует как вызывающий объект и гарантирует, что тестируемый код (независимо от размера - отдельная функция или огромная вложенная библиотека, проверка которой занимает 30 минут) возвращает результаты предсказуемым образом.
Суть модульного тестирования - обеспечить совместимость (не нарушая взаимодействия) и гарантировать предсказуемые результаты. Тестирование в любом месте, где происходит обмен информацией, поможет стабилизировать ваше приложение.
ОБНОВЛЕНИЕ: Я также всегда добавлял модульный тест, когда заказчик или пользователь сообщает о пограничном случае, который нарушает взаимодействие в моем приложении. Исправить это не
Я бы сказал, что единица - это наименьшая значимая часть работы, которую можно отделить от других шагов в псевдокоде.
Например, если вы пытаетесь выполнить серию шагов для обработки некоторых данных, таких как
- сканировать набор данных для минимального, максимального, среднего, среднего
- генерировать гистограмму
- генерировать повторное сопоставление функция
- переназначает данные
- выводит данные
Каждый из этих шагов будет «единицей», и вся серия сама по себе также является «единицей» (чтобы проверить, работает ли согласованность между каждым из них) . Любой из этих шагов может быть четырьмя функциями (для первого шага, если программист запускает четыре цикла), или одной функцией, или чем-то еще, но, в конце концов, известные входные данные должны давать известные выходы.
Nothing is trivial, if you take into account the Murphy's Law.
Jokes apart and assuming an OO environement, I approach Unit Testing taking a class as the unit, because often the various methods modify the internal state and I want to be sure that the state between various methods is consistent.
Unfortunately, often the only way to check consistency is to invoke various method of a class to see if they fail or not.
В общем, чем меньше вы можете сделать свои модули, тем полезнее и эффективнее будут ваши модульные тесты. Весь смысл модульных тестов состоит в том, чтобы иметь возможность локализовать любую недавно появившуюся ошибку в небольшой части кода.
Для меня «единица» - это любое существенное поведение класса, которое через 8-12 месяцев я не буду вспоминать.
И с хорошо- написанные модульные тесты (подумайте BDD ), мне не придется, потому что мой тест будет описывать и проверять код на простом английском языке.
Изменяйте размер блока, пока он уже не тривиально? Кто, черт подери определил единицу кода как единый в любом случае функция или метод!?
Если слишком сложно протестировать «модуль», определенный как метод, то, вероятно, метод слишком велик или сложен для создания модульного теста.
Я следую аналогичному методология, предложенная rwmnau , и проверка на уровне метода. Помимо создания одного теста для каждого метода, я создаю дополнительные тесты для разных путей кода в каждом методе. Иногда может быть сложно выделить все пути кода. Моя задача - избегать написания типов методов, если нет лучшего решения с точки зрения производительности и сложности кода.
Я также использую имитацию для тестирования контрактов между компонентами.
Я подозреваю, что «единичное тестирование» является неправильно используемым термином. В настоящее время этот термин используется не только для проверки небольшого фрагмента кода, но и для любого автоматизированного теста.
Я, как правило, пишу свои тесты перед написанием своего кода, так что я не могу сказать вам, когда я впервые пишу его, если это приведет к созданию нескольких новых строк, нового метода или нового класса.
Итак, словом: мю .