Заглушка объектов с входными аргументами - PullRequest
0 голосов
/ 10 марта 2009

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

dim = getDimension(self,dimensionName,otherIndentifyingInformation)

(Это все в MATLAB - надеюсь, ответ не зависит от языка или, по крайней мере, недостижим в MATLAB.)

Когда я использую его в своем коде, dimensionName - это одна из немногих вещей, которые хранятся в базе данных. Если код вызывает его, а он не существует, это нормально. Проблема в том, что я хочу протестировать некоторый код, который делает два вызова getDimension, что-то вроде:

alt = conn.getDimension('alt',otherID);
str = conn.getDimension('str',otherID);

По (надеюсь) очевидным причинам, alt и str не обязательно будут одинаковыми. На самом деле, они, как правило, нет.

Итак, мой вопрос. Если я хочу заглушить getDimension, чтобы вернуть хорошие тестовые значения, как я могу это сделать? Создание getDimensionAlt кажется глупым, поскольку число вещей, которые могут появиться из базы данных, несколько неограниченно, и это было бы трудно поддерживать. Есть ли лучший способ, чем поместить логику в мои объекты-заглушки? Это просто кажется неправильным путем ...

РЕДАКТИРОВАТЬ: была предложена настройка testDB. Разве мне не пришлось бы устанавливать testDB для каждого тестового случая? И в каждом тесте мне нужно было создать соединение с БД, вернуть его как заглушку, запустить тест, а затем очистить соединение с БД. Похоже, что для каждого теста это будет очень сложно, особенно если это не та система, которую я тестирую.

Полагаю, можно установить testDB и каждый раз заполнять его соответствующими значениями. Это хорошая практика?

РЕДАКТИРОВАТЬ 2: Возможно, мой вопрос неясен. У меня есть небольшой кусок кода, который я пытаюсь проверить. Это не намного сложнее, чем те две строки выше, и я хотел бы проверить это чисто. Проблема в том, что заглушка вызова getDimension зависит от аргументов. Мне не нужно повторно использовать эту заглушку с другими тестами.

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

Ответы [ 3 ]

0 голосов
/ 10 марта 2009

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

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

Хорошей идеей является использование заглушек в модульных тестах. Проблема, с которой вы, кажется, сталкиваетесь, заключается в том, что если вы хотите повторно использовать заглушки для многих тестов, их поведение может быть очень сложным, в худшем случае вы перестраиваете то, за что они должны стоять. Это также может произойти, если вы тестируете слишком много за один раз.

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

0 голосов
/ 10 марта 2009

Мой ответ на похожий вопрос Создание фиктивных данных для модульного тестирования :

Вы можете иметь класс (ы) Builder, которые поможет вам создать примеры, которые вы нужны / в этом случае те, которые вы бы использовали связанные с хранилищем. Есть Builder использует соответствующие значения по умолчанию и на ваших тестах вы можете переписать то, что тебе нужно. Это поможет вам избежать необходимости поставить у каждого случая «данные» смешались для всех разных тесты (что создает проблемы, потому что обычно бывают случаи, когда не совместимы для разных тесты).

Обновление 1: взгляните на www.markhneedham.com/blog/2009/01/21/c-builder-pattern-still-useful-for-test-data

Также проверьте этот ответ относительно общего отношения модульных тестов к внешним системам: Как улучшить мои тесты Junit

Обратите внимание, что есть альтернатива, использующая базы данных в памяти, такие как dbunit. Я предпочитаю строителя по причинам, указанным в следующей ссылке.

0 голосов
/ 10 марта 2009

Не могли бы вы создать тестовую базу данных с известными значениями, а затем выполнить известный набор запросов к ней (с известными ожидаемыми возвращаемыми значениями)?

...