2009-06-16 2 views
7

Есть ли способ показать прогресс одного TestMethod в Visual Studio 2008?Возможно ли показать прогресс во время выполнения TestMethod Visual Studio?

В комплекте модульных тестов у меня есть один TestMethod, который работает очень и очень долго - обычно это займет от 30 до 60 минут. Я установил Timeout с использованием атрибута [Timeout], без проблем. Но я хотел бы получить визуальное представление о ходе теста.

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


EDIT: Я знаю, что есть способ сделать это; это всего лишь программное обеспечение, поэтому всегда есть способ. Но что является простым, практичным способом?

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

Другим вариантом является создание TestMethodProgressMonitor.exe в качестве COM-сервера, а TestMethod может использовать COM (DCOM) для обновления размещенной строки выполнения в приложении.

Другой вариант - использовать метод SendMessage() user32.dll для отправки сообщения WM_COPYDATA в приложение-монитор. Иногда это делается для удаленного управления приложениями.

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

+0

единичный тест, который занимает так много времени, не является единичным тестом на каждое определение. Зачем это так долго? –

+2

Это тест создания файла ZIP64; Тест шифрует набор файлов, которые приводят к zip-файлу размером более 4 ГБ. Затем zipfile обновляется и сохраняется снова (дважды). Код составляет около 5 строк, окруженных петлей. Но есть много и много ввода-вывода и много DEFLATE. Вы действительно говорите, что определение модульного теста включает ограничение по времени? Каков срок? – Cheeso

ответ

5

Я просто начать GUI нить с окном, которое имеет ProgressBar.

Вот фрагмент, который поможет вам начать работу. Он просто вызывает MyProgressWindow в другом потоке (а не в другом процессе).

[ClassInitialize()] 
static public void MyClassInitialize(TestContext testContext) 
{ 
    start_app_in_gui_thread(); 
} 

static Thread t; 

private static void start_app_in_gui_thread() 
{ 
    t = new Thread(() => { 
     var w = new MyProgressWindow(); 
     var app = new App(); 
     app.ShutdownMode = ShutdownMode.OnMainWindowClose; 
     app.Run(w); 
    }); 
    t.SetApartmentState(ApartmentState.STA); 
    t.Start(); 
} 
+0

Дох! Что это значит? Whadaya означает «запустить поток GUI»? – Cheeso

+0

Извините за жаргон. Вот какой код. Наслаждаться. – Ray

1

Для моих длительных тестов я использую API для трассировки, чтобы прикрепить прослушиватель трассировки (DbgView или что-то обычай).

Делает его мертвым простым, чтобы видеть, что происходит, без необходимости прыгать через любые обручи.

Это не даст вам опыт работы с баром (хотя вы можете написать довольно легко).

+1

Отлично! Кстати, использование System.Diagnostics.Debug позволяет даже видеть результат в окне «Вывод» – sinelaw

0

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

Затем я создал приложение winforms (UnitTestProgressMonitor.exe), которое создает один из этих приемопередатчиков, и обновляет его интерфейс на основе полученных им сообщений. Сообщения - это просто строки.Это то, что они делают:

  • бары 3 - Пользовательский интерфейс создает и отображает 3 прогресс баров
  • рь 0 макс 100 - устанавливает максимальное для прогресса бар # 0 до 100
  • рь 0 значение 28 - наборы значение для индикатора выполнения от 0 до 28
  • остановка - выход.

Затем, в рамках [TestMethod], I shellexec UnitTestProgressMonitor.exe, затем создайте приемопередатчик и отправьте сообщения приложения.

Тестовый код отправляет «бары 3» в приложение монитора прогресса, чтобы сообщить ему о создании 3 индикаторов выполнения. Первый отслеживает 7 шагов теста. Второй индикатор прогресса измеряет прогресс в zip-файле; каждая запись в файле является шагом вдоль строки. Третий бар - это прогресс для отдельной записи. Некоторые из них представляют собой файлы с несколькими гигабайтами, поэтому их сжатие может занять некоторое время. Во время выполнения теста тест отправляет «pb 0 step» или что-то еще в соответствующие моменты времени. Эти сообщения приводят к обновлению индикаторов выполнения. В конце теста тестовый код отправляет «стоп» в приложение монитора. В ответ на это приложение мониторинга прогресса исчезнет. Тест заканчивается.

Unit Test Progress Monitor http://www.freeimagehosting.net/uploads/45b4979b92.jpg

1

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

[TestMethod] 
    public void ProgressTest() 
    { 
     int nLastWritten = -1, nTotal = 10000; 

     for (int i = 0; i < nTotal; i++) 
     { 
      int nProgress = 100 * i/nTotal; 
      if (nProgress > nLastWritten) 
      { 
       System.Diagnostics.Trace.WriteLine("Progress: " + nProgress + "%"); 
       nLastWritten = nProgress; 
      } 
     } 
    }