Практика проектирования: код для создания перед удалением в тестовом случае удаления?

Question

Я написал тестовый пример для удаления объекта. В тестовом примере я просто выбираю первую запись по запросу select и передаю ее идентификатор методу удаления. У сущности, которую я хочу удалить, могут быть некоторые дочерние сущности, ограничивающие ее удаление. Таким образом, я полагаю, что сначала я должен создать сущность в моем тестовом случае удаления, а затем уничтожить ее, чтобы не сталкиваться с проблемами дочерней зависимости. Это хорошая практика, чтобы написать код для создания объекта перед удалением. Это своего рода метод создания теста перед удалением. Пожалуйста, предложите

Edit: Я работаю на платформе Rail, поэтому у меня есть такие функции, как загрузка базы данных с помощью осветителей (в настоящее время я не использую, сталкиваюсь с некоторой ошибкой, см. https://stackoverflow.com/questions/5288142/rails-fixture-expects-table-name-to-be-prefixed-with-module-name-how-to-disable). И да, я использую конфигурацию для восстановления состояния базы данных после запуска тестового примера.

Answer 1

В модульном тестировании вы обычно выполняете какие-то настройки перед запуском тестов.

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

Поскольку вы в первую очередь создаете объект, вы не тестируете код запроса на создание.(если только способ внутреннего создания объектов не является ошибочным, но если вас это беспокоит, вы тоже можете это проверить), и ваш код удаления - единственное, что проверяется.

Answer 2

Рекомендуется ли писать код для создания сущности перед удалением. Это своего рода метод создания теста перед удалением. Пожалуйста, предложите

Да, рекомендуется создать объект, удаление которого вы тестируете, чтобы тест не зависел от внешнего состояния и повторялся независимо от других тестов.

Это не создание теста , но использует создание для настройки проверки удаления.

Если у вас есть несколько тестов, основанных на одних и тех же данных, создание может быть извлечено в метод, который вы вызываете в каждом из ваших тестов, которым нужны эти данные. Большинство тестовых сред также имеют механизм для указания setup методов, которые запускаются перед каждым тестом, и вы можете поместить туда создание, если данные необходимы для всех тестов в тестовом классе.

Answer 3

Если ваша инфраструктура модульного тестирования допускает тестовые зависимости, т. Е. Запускать тест X только в том случае, если тест Y пройден и передается возвращаемое значение Y в качестве параметра X, вы можете обойтись без него.Вот как это будет выглядеть в PHP:

function setUp() {
    $this->dao = new UserDao(...);
}

function testCreate() {
    $user = $this->dao->create('Bob');
    assertThat($user, notNullValue());
    // more assertions about the new user
    return $user->getId();
}

/**
 * @depends testCreate
 */
function testDelete($id) {
    assertThat($this->dao->delete($id), is(true));
}

PHPUnit пропустит testDelete (), если testCreate () завершится неудачно.Это хороший обходной путь, если вы не можете настроить стандартный набор тестовых данных перед каждым тестом.

Answer 4

В тестовом примере я просто выбираю первую запись по запросу select

Это неправильно.Вы не должны выполнять запросы во время модульного тестирования.

Тест, который я вижу, может быть:

1. Удалить существующее;
2. Удалить несуществующую сущность;
3. Удалить ребенка;
4. Удалить несуществующего ребенка;