Как интегрировать тестовое консольное приложение в решение?

У меня есть консольное приложение (которое позже будет установлено как служба Windows), которое в основном запускает бесконечный цикл, который читает сообщения из очереди и что-то делает с этим сообщением.Как интегрировать тестовое консольное приложение в решение?

Я хотел бы создать автоматизированный тестовый пример, чтобы запустить тестовое сквозное поведение. Мой вопрос: какой лучший способ запустить приложение в модульном тесте? Я использую Process.Start? или я могу напрямую ссылаться на Program.cs - static void main и запускать это?

идеи? образец кода был бы оценен, спасибо!

[Обновить: Да, я знаю, что это интеграционный тест. Я обновил название. Я уже отделил свою логику бизнес-логики. Значение интеграционного тестирования - это сделать это автоматическим способом. Это гарантирует, что все мои настройки конфигурации верны, там мои проблемы с версиями сборки в порядке, мои записи и доступ к базе данных, а также доступ к очереди и кэш-памяти и т. Д.]

источник

2015-09-25 Raymond

В идеале у вас будет класс в вашей программе Program.cs, который будет работать для вас. Таким образом, вы Program.cs просто создали и вызывают любой метод в этом классе. Таким образом, если у вас есть зависимости в консольном приложении (например, данные), вы можете ввести их в свой модульный тест. –

Если вы говорите о ** модульном тестировании ** ... как насчет тестов для каждого отдельного класса (строго говоря) в вашем приложении? Вы не должны тестировать приложение вместе, а его компоненты. Также с угловыми футлярами ваше приложение (как черный ящик), вероятно, не получит/не получит. Для тестирования интеграции затем запустите приложение с помощью Process.Start(), вызвав его классы напрямую, это сломает тест, потому что ваш стенд будет/может сильно повлиять на его среду. –

Когда я создаю этот тип установки, вся работа в отдельной DLL. Приложение Windows Service/Console находится в крошечном проекте, который делегирует большую часть работы DLL. Большинство функциональных тестов происходит против этой DLL.

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

Убедитесь, что у вас есть подходящее средство для прекращения приложения консоли (например, отправка сообщения «shutdown») и убедитесь, что процесс действительно завершается в модульном тесте.

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

источник

2015-09-25 20:18:07

Существует родственный article in Code Project, который рекомендует условной компиляции для отладки:

static class Program 
{ 
    static void Main() 
    { 
     #if(!DEBUG) 
      ServiceBase[] ServicesToRun; 
      ServicesToRun = new ServiceBase[] 
     { 
      new MyService() 
     }; 
      ServiceBase.Run(ServicesToRun); 
     #else 
      MyService myServ = new MyService(); 
      myServ.Process(); 
      // here Process is my Service function 
      // that will run when my service onstart is call 
      // you need to call your own method or function name here instead of Process(); 
     #endif 
    } 
}

источник

2015-09-25 20:19:14

Он (предположительно) уже делает это. Его вопрос заключается в том, как тестировать программу, а не как компилировать как службу, так и консольное приложение. –

Да, вы можете ссылаться на EXE-файл и вызывать main если вы сделаете его общедоступным:

public class Program 
{ 
    public static int Main(string[] args) 
    { 
     // Implementation here... 
    } 
}

Это Wouldn» t - единичный тест, хотя, как указывали другие.

источник

2015-09-25 20:20:14

Как интегрировать тестовое консольное приложение в решение?

ответ

Смежные вопросы