Как управлять тестовыми приборами для сквозного тестирования?

Question

Просто настроив среду тестирования для нового веб-приложения, я понял, что пропустил один из важных вопросов: "Как сделать тесты независимыми друг от друга?"

Несколько лет назад я создал несколько сложных сценариев Ant для полного цикла удаления всех таблиц базы данных, повторного создания схемы, добавления тестовых данных, запуска приложения, запуска одного теста и затем остановки приложения. Это было трудно поддерживать и ограничивало нас ночными тестами из-за времени, которое потребовалось для запуска полного пакета. Это все еще стоило того, но мне интересно, есть ли более легкий путь.

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

Answer 1

Для справки: то, что я сейчас делаю, - это настроенный в приложении специальный ресурс, который сбрасывает всю базу данных (удаляет весь контент, добавляет пользователя по умолчанию). Этот ресурс привязан к URL-адресу только в том случае, если приложение запущено в "тестовом режиме". Поскольку наше приложение (в основном) RESTful, добавление новых объектов может быть выполнено извне. Базовый класс наших тестов вызывает ресурс во время настройки тестового примера.

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

Answer 2

Настройка базы данных для тестирования может сделать вещи быстрее. Ofc. это зависит от типа используемой вами базы данных... С помощью тестов интеграции базы данных вы можете просто откатить свои транзакции. С помощью других интеграционных тестов вы можете просто смоделировать слой доступа к данным.

По функциональным тестам у вас нет выбора, кроме как протестировать вашу систему с реальной базой данных...

В настоящее время я экспериментирую с источником событий, который может очень помочь, делая приспособления. Кратчайшее описание этого метода: вам нужно DDD (и CQRS также рекомендуется), сохранить доменные события в хранилище событий, и после этого вы можете построить текущее состояние, получив связанные события из хранилища событий, и воспроизвести их в последовательность. Поверх этого хранилища событий можно построить множество различных кеш-баз данных, которые содержат только текущее состояние компонента вашего сервиса, и ничего более... Процесс синхронизации выполняется классами, называемыми проекциями, и называется автоматически синхронизирующими или асинхронными. сохраняя событие. Таким образом, чтобы сделать фикстуру, нужно хранить только доменные события...

Например, вы можете написать что-то вроде этого с помощью очень простого REST API:

изготовление крепежа:

event.storage.clear();
every.cache.clear();

var credentials = {
    name: "infje",
    password: "oéö9péüöáé9oilusw"
};
var resourceId = "swegretz34ze4wed";
var userDataSet = [
    {
        id: 1,
        type: "UserCreate",
        resource: resourceId,
        identificationFactors: credentials,
        nick: "inf3rno",
        birthDate: "1333.03.03.",
        hobbies: ["wall climbing"]
    },
    {
        id: 2,
        type: "UserUpdate",
        resource: resourceId,
        hobbies: ["base jumping", "knitting"]
    }
];

event.storage.persistAll(userDataSet);
auth.cache.sync(event.storage); //a relational database with the user credentials
users.cache.sync(event.storage); //a nosql document database with the user profile

функциональный тест:

var response = http.get("https://my.test.api/users", credentials);
assert(response).toEqual({
    size: 1,
    items: [
        {
            id: resourceId,
            nick: "inf3rno",
            hobbies: ["base jumping", "knitting"],
            birthDate: "1333.03.03."
        }
    ]
});

примечание: это просто доказательство концептуального кода, поэтому такие детали, как шифрование пароля, ограничение гипермедиа REST, автоматический вызов классов проекции и т. д., сейчас не актуальны.

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

Answer 3

Конечно... посмотрите на непрерывное интеграционное тестирование с помощью CruiseControl. Вы можете использовать это вместе с NAnt и NUnit для запуска ваших тестов, разрушения и настройки среды, а также множества других вещей. И это можно запускать каждый раз, когда кто-то проверяет свой код в вашем хранилище кода. Это единственный способ сделать код!