Мы только начинаем писать интеграционные тесты для тестовой базы данных, уровня доступа к данным, вызовов веб-сервисов и т. Д. В настоящее время у меня есть идея написать интеграционные тесты, такие как 1) Постоянное воссоздание таблиц в функции инициализации. 2) Всегда очищайте данные внутри функции, если вы сохраняете новые внутри той же функции.
Но хотелось бы узнать еще несколько хороших практик.
При модульном тестировании DAL я делаю это так:
[TestFixtureSetUp]
public void TestFixtureSetUp()
{
//this grabs the data from the database using an XSD file to map the schema
//and saves it as xml (backup.xml)
DatabaseFixtureSetUp();
}
[SetUp]
public void SetUp()
{
//this inserts test data into the database from xml (testdata.xml)
//it clears the tables first so you have fresh data before every test.
DatabaseSetUp();
}
[TestFixtureTearDown]
public void TestFixtureTearDown()
{
//this clears the table and inserts the backup data into the database
//to return it to the state it was before running the tests.
DatabaseFixtureTearDown();
}
Как и при любом тестировании, обязательно начинать с известного состояния, а по завершении теста переходить в чистое состояние.
Кроме того, тестовый код часто упускается из виду как ненастоящий и, следовательно, не поддерживается должным образом ... он важнее кода. По крайней мере, столько же дизайна должно входить в архитектуру ваших тестов. Планируйте разумные уровни абстракции, т.е. если вы тестируете веб-приложение, подумайте о наличии таких уровней: абстракция взаимодействия с вашим браузером, абстракция ваших компонентов на страницах, абстракция страниц и ваши тесты. Тесты взаимодействуют со страницами и компонентами, страницы взаимодействуют с компонентами, компоненты взаимодействуют с уровнем взаимодействия браузера, а уровень взаимодействия браузера взаимодействует с вашей (возможно, сторонней) библиотекой автоматизации браузера.
Если ваш тестовый код не поддерживается должным образом или не продуман, он становится больше помехой, чем помощником в написании нового кода.
Если ваша команда новичок в тестировании, существует множество ката кодирования, которые стремятся Чтобы научить важности хороших тестов (а из этого и получается хороший код), они обычно сосредотачиваются на уровне модульного тестирования, однако многие принципы одинаковы.
В общем, я бы посоветовал вам изучить имитацию уровня доступа к базе данных и классов вызовов веб-сервисов, чтобы сделать их более тестируемыми. Есть много книг по этой теме, например, Искусство модульного тестирования Ошерова.
При этом интеграционные тесты должны быть повторяемыми. Таким образом, я бы выбрал вариант 1, чтобы написать сценарий, который может воссоздать базу данных с нуля с тестовыми данными. Вариант 2 сложнее, потому что трудно быть уверенным, что функция очистки не оставит нежелательных остатков данных.
