Как начать автоматизированное тестирование большого приложения?

Question

РЕДАКТИРОВАТЬ: Благодаря комментаторам ncie, я получаю разницу между модульным и автоматическим тестированием, поэтому я переименовал тему

Окружение: .net 2.0, SQL Server 2005, Windows Server 2003

Я читал эту статью:

http://www.codeproject.com/KB/tips/convince.aspx

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

И я долженскажи, что эта статья действительно классная, и заставь меня попробовать!

Итак, наша система почти одинакова: все данные доступны через веб-сервисы, поэтому мы можем легко (например, с soapui) сделать некоторыеавтоматическое тестирование этих веб-сервисов.

НО: как насчет базы данных?Чтобы провести автоматическое тестирование, нам нужно иметь в базе данных правильные данные, соответствующие автоматическому тесту.

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

вот как я могу это сделать:

• создать сервер свсе, что нужно (iis, sql server ...)
• добавьте что-нибудь, чтобы дата этого сервера никогда не менялась, поэтому мне не нужно менять время в моем автоматическом тесте
• add inВ моей базе данных есть записи, необходимые для моего автоматического теста

ПРОБЛЕМА: после 10 автоматических тестов база данных станет большим беспорядком, и я никогда не узнаю, какая запись для какого автоматизированного теста.Идея состоит в том, чтобы добавить столбец "TEST_NAME" к каждой таблице, но это немного грязно в моей памяти.

Так вы когда-нибудь пробовали такую ​​технику?Вы использовали какие-то конкретные инструменты?Мой образ мышления хороший?(или, по крайней мере, хороший).

Спасибо

РЕДАКТИРОВАТЬ: я получил 2 -1 для этой темы, я хотел бы знать, почему, поэтому я не буду делать ту же ошибку дважды.

Answer 1

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

Слои данных часто являются простым делом вставки и извлечения, поэтому предположим, что вы можете преобразовать свой слой данных в интерфейс, подобный:

interface IRepository
{
   GetModel(id);
   SaveModel(model);
}

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

Answer 2

Если вы можете генерировать свои тестовые данные перед каждой партией тестов, тогда ваши записи должны начинаться с идентификатора, равного следующему числу, кратному 100. Поэтому, если самая большая запись равна 350, сгенерируйте, начиная с 400, и протестируйте с 400 и выше , Когда ваша БД станет действительно большой, удалите все.

Answer 3

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