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

Question

Имея только set up a test framework for a new web application, я понял, что пропустил один из больших вопросов: «Как я могу сделать тесты независимыми друг от друга?»

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

Я в настоящее время экспериментирую с источниками событий, которые могут помочь много, делая светильники. Краткое краткое описание этого метода: вам нужен 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 гипермедиа ограничение, автоматизац c вызовом проекционных классов и т. д. ... сейчас не актуальны.

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