База данных поблочного тестирования управляемые приложения.NET
Зависит от типа хэш-таблицы, которую Вы создаете. При использовании фиксированной основанной на массиве хэш-таблицы (в противоположность связанным спискам для блоков), необходимо изменить размеры массива или когда таблица полна или когда Вы поразили макс. тестовое количество (в зависимости от того, заботитесь ли Вы больше о скорости или памяти). При использовании связанных списков память не является таким же большим беспокойством с тех пор и не должна зондировать для вакуумов, таким образом изменение размеры не является столь же большим из соглашения.
ключ с хэш-таблицами является алгоритмом хеширования, не количеством блоков. Идеально, Вы всегда хотите самое большее один объект в каждом блоке, таким образом, необходимо идеально изменять размеры когда количество объектов в хэш-таблице = количество блоков. Если Ваши данные не равномерно распределяются, Вы лучше из с лучшим хеш-алгоритмом, чем лучшее изменяет размеры стратегии.
8 ответов
Ответ - насмешка
Однако я нашел способ сделать это следующим образом:
Разделите DAL на 2 уровня. Внизу просто выполняется атомарное чтение и запись в базы данных - все эти объекты реализуют набор интерфейсов IReadFromDB и IWriteToDB.
Затем вы можете создать свою бизнес-логику чтения и записи на более высоком уровне DAL, но вместо того, чтобы ссылаться на объекты, которые будут читать и писать в базу данных, ссылаться на интерфейсы и использовать свойства, чтобы иметь возможность заменять функциональность. Я стараюсь включать желаемые функциональные объекты в конструкторы, чтобы все работало «из коробки», так сказать.
Это упростит «замену» функциональности и, таким образом, модульное тестирование бизнес-логики.
Что касается тестирования чтения и записи БД ... Я не нашел способа, который бы не Обычно я использую другую строку подключения к копии базы данных, а затем пишу код генерации данных и очистки для модульных тестов, чтобы оставить состояние базы данных таким же, как до и после.
Да, это требует много времени ... однако это не рискует оттолкнуть клиента. Это зависит от ваших приоритетов.
Кто-то упомянул тестирование производительности. Я бы не стал рассматривать это как часть модульного теста. Я обычно делаю это с помощью тестовой оснастки в сочетании с отладочным кодом просто потому, что производительность мелких частей часто вводит в заблуждение - когда вы переходите к общей картине, части, которые на самом деле создают проблемы, часто не являются частями, которые локализованное тестирование отметило бы, по моему опыту .
У меня есть два метода для кода модульного тестирования, который зависит от базы данных:
- Мок-объекты, т.е. TypeMock
- Пользовательские сценарии SQL, выполняемые в подпрограммах TestInitialise () и TestCleanup (). .
С TypeMock я могу подделывать данные базы данных, поступающие в мой код, что помогает мне запускать мои тесты, не беспокоясь об очистке базы данных, восстановлении резервных копий и т. Д. Я использую имитацию для тестирования кода вне логики базы данных, но по-прежнему требуются поддельные данные из базы данных.
С помощью пользовательских сценариев SQL я могу запускать команды SQL в подпрограмме TestInitialise (), а после завершения модульного теста я выполняю SQL-запрос очистки на подпрограмме TestCleanup (). Я использую этот метод для тестирования кода, где логика базы данных более сложна. Например, мне может потребоваться вставить несколько строк в таблицы, которые помогут при тестировании кода.
Я думаю, что лучшая практика - это смоделировать весь доступ к базе данных - просто вернуть некоторые заранее определенные статические данные по вызову - вам не нужно проверять, как работают базы данных - вам нужно проверить свое устройство поведение. Меньше ваш модульный тест взаимодействует с внешним миром - лучше.
С издевательством вы сможете проверить, что вызов к базе данных действителен, не вызывая его, так что я думаю, это то, что вам нужно.
Я бы рекомендовал имитировать уровень доступа к данным. Преимущества использования моков в этом случае включают: 1) юнит-тесты будут выполняться быстрее. Если им придется выполнять всю работу по подключению к базе данных, извлечению данных и т. Д., Тогда стоимость будет увеличиваться. Дорогие тесты = люди перестают их проводить / начинают терять в них веру! 2) Вы можете протестировать широкий спектр сценариев без необходимости настраивать подходящие тестовые / статические данные, которые вы должны гарантировать, что они всегда находятся в БД до начала тестов. 3) исключение внешней системы БД из уравнения означает, что вы тестируете только тот код .NET, который хотите протестировать. Никакой внешней зависимости.
У вас может быть уровень доступа к данным, который выполняет чистое взаимодействие с БД, а затем имитировать это. Или используйте фиктивные SqlCommands и т. Д. В своем коде .NET.
Вы должны попытаться разбить свой код так, чтобы вы могли имитировать работу ваших функций.
Уровень, который действительно должен взаимодействовать с базой данных, может использовать систему настройки данных и работы с ними в рамках транзакции, которую вы должны откатить в конце теста.
Я думаю, вам следует разделить свои проблемы на разные виды тестов.
- Напишите модульные тесты для логика манипулирования данными, реализованная в .NET. Либо имитируйте базы данных, либо полностью отделите логику массирования данных от материала доступа к данным и просто загрузите свою процедуру обработки данных предварительно запеченными входными данными.
- Создайте интеграционный тест, который проверяет весь поток данных. Этот тест также следует автоматизировать. Установите исходную и целевую базы данных (либо из сценария БД, либо из резервной копии БД) в известное состояние, запустите логику обработки данных, затем проверьте результаты.
- Вы также можете создать тесты производительности и стресс-тесты, если вы имеете дело с большим количеством данных. Вы можете настроить базы данных так же, как и в интеграционном тесте, сгенерировать набор тестовых данных, запустить свой компонент и проверить либо время выполнения, либо его выполнение вообще (например, отсутствие проблем с параллелизмом, взаимоблокировок, и т. д.)
Я бы абстрагировался от уровня доступа к данным, а затем имитировал бы его. С помощью mocking вы сможете увеличить охват кода ваших тестов. Это также предотвратит идею « Test Cancer », которая может произойти из-за выполнения дорогостоящих вызовов сети / файловой системы / базы данных, потому что люди перестанут их запускать.
У вас должно быть несколько тестов, которые обращаются к базы данных, но они должны быть максимально ограничены.
В моей работе мы используем Nunit и Typemock для нашего модульного тестирования. То, что нам не нужно менять код для тестов, - большой плюс. Издевательство над DAL - лучший вариант.