В моем последнем посте я рассмотрел новую платформу Microsoft Integration Testing для веб-приложений, облегченную среду автоматизации тестирования. Я получил некоторые отзывы от одного из разработчиков для фреймворка, и я решил взглянуть на то, как мы можем решить некоторые из вопросов, которые я поднял, а не просто жаловаться на них.
Во-первых, они начали называть проект LTAF, поэтому я буду делать то же самое.
В этом посте я попытаюсь решить одну из моих основных проблем с фреймворком — отсутствие автоматической поддержки сборки. Хотя поддержка интеграции с процессом сборки находится в стадии разработки, я напишу быструю реализацию, которая может использоваться до тех пор. Это было сделано с помощью июньского обновления LTAF .
Написание теста Runner
Поскольку интерфейс для запуска тестов является веб-интерфейсом, самой простой реализацией для тестировщика будет автоматизация веб-запросов. Есть два способа сделать это — мы можем вручную создать HttpWebRequest с помощью метода WebRequest.Create () или использовать элемент управления System.Windows.Forms.WebBrowser . Оба метода имеют свои преимущества и недостатки: с помощью HttpWebRequest нам нужно вручную передать ответ, а с помощью элементауправления WebBrowser нам нужно работать в поточной модели Single-Threaded-Apartment (Sta). Я решил использовать элемент управления WebBrowser, так как на странице будет работать javascript, который вы не можете сделать с помощью HttpWebRequest .
Автоматизация запроса
LTAF содержит поддержку выбора и запуска тестов через параметры, переданные в URL. Механизм по умолчанию для выбора тестов состоит в том, чтобы пометить их определенным тегом (в коде) и затем указать этот тег в URL. Мы также можем указать, что тесты должны запускаться автоматически, а результаты должны регистрироваться. В этом случае мы хотим запустить все тесты, поэтому URL будет выглядеть примерно так:
HTTP: // локальный: 54497 / SampleWebSite / Тест / тег = все и войти = верно и пробег = истина
Если вы откроете этот URL в своем браузере, все тесты будут выполнены, и результаты будут записаны в файл с именем TestLog.txt в том же каталоге, что и тестовая страница (по умолчанию это в папке \ Test ).
Давайте напишем некоторый код
Я реализовал бегун как консольное приложение. Я также передаю 2 параметра через командную строку: URL-адрес веб-сайта и каталог, в котором находится веб-сайт.
Единственная сложная часть — знать, когда запуск завершен — поскольку тесты выполняются в основном с помощью javascript, самый простой способ сделать это — отслеживать файловую систему, чтобы увидеть, когда результаты записываются в файл. В моей реализации я проверяю файловую систему каждую секунду для файла результатов.
public void RunTests()
{
File.Delete(Path.Combine(Arguments.WebDirectory, @"Test\Startup.txt"));
File.Delete(Path.Combine(Arguments.WebDirectory, @"Test\TestLog.txt"));
browser = new WebBrowser();
browser.Navigate(Arguments.WebUrl + @"/Test/?tag=all&log=true&run=true");
new Thread(CheckForRunCompleted).Start();
}
private void CheckForRunCompleted()
{
var logFile = Path.Combine(Arguments.WebDirectory, @"Test\TestLog.txt");
while (true)
{
if (File.Exists(logFile))
{
break;
}
Thread.Sleep(1000);
}
CompletedEvent(logFile);
}
Консольное приложение анализирует аргументы, запускает запрос и записывает результаты в окно консоли.
class Program
{
[STAThread]
static void Main(string[] args)
{
var arguments = ArgumentParser.Parse(args);
if (arguments != null)
{
var host = new BrowserHost(arguments);
host.CompletedEvent += RunCompleted;
host.RunTests();
Application.Run();
host.CompletedEvent -= RunCompleted;
host.Dispose();
}
}
private static void RunCompleted(string logFile)
{
foreach (var line in File.ReadAllLines(logFile))
{
if (line.Contains("Testcase FAILED"))
{
Environment.ExitCode = -1;
}
Console.WriteLine(line);
}
Application.Exit();
}
}
Ничего подобного. Для запуска тестов сначала необходимо разместить свой веб-сайт либо через ASP .Net Development Server, либо через IIS. По умолчанию Visual Studio будет размещать ваш сайт на сервере разработки.
Непрерывная интеграция
Когда запуск завершен, я записываю вывод в окно консоли и ищу любые неудачные тесты. Установка кода выхода должна указывать на сбой — для большинства решений непрерывной интеграции это должно приводить к сбою сборки.
К сожалению, результаты из файла журнала не очень информативны — я бы предпочел увидеть время, затраченное на выполнение каждого теста, а также трассировку стека от любых неудачных тестов.
Свежие комментарии