Преобразование тестового приложения домашнего приготовления в стандартную платформу модульного тестирования

Question

У меня есть МНОГО тестов, написанных для части программного обеспечения (и это ОТЛИЧНАЯ вещь), но по сути, оно было создано как отдельный тест на C #.Хотя это работает достаточно хорошо, оно страдает несколькими недостатками, не последним из которых является то, что в нем не используется стандартная платформа тестирования и в конечном итоге требуется, чтобы человек, выполняющий тест, комментировал вызовы тестов, которые не следует запускать (когда нежелательно запускать весь тестовый "набор").Я бы хотел включить это в свой автоматизированный процесс тестирования.

Я видел, что в тестовой версии VS 2008 есть понятие "Универсальный тест", который может делать то, что я хочу, но в настоящее время мы не в состоянии тратить деньги на эту версию.Недавно я начал использовать версию VS 2008 Pro.

Эти методы тестирования следуют знакомой схеме:

• Сделайте некоторые настройки для теста.
• Выполните тест.
• Выполните сброс для следующего теста.

Каждый из них возвращает bool (pass / fail) и строку ref с указанием причины сбоя, заполняемую в случае сбоя.

С другой стороны, по крайней мере, методы тестирования непротиворечивы.

Я сижу здесь сегодня вечером, обдумывая подход, который я мог бы применить завтра утром, чтобы перенести весь этот тестовый код на платформу тестирования, и, честно говоря, я не в восторге от идеи вручную просмотреть 8-9 тысяч строк тестового кода для выполнения преобразования.

Был ли у вас какой-либо опыт проведения такого преобразования?У вас есть какие-нибудь советы?Я думаю, что, возможно, я застрял, пробираясь через все это, выполняя глобальный поиск / замены и вручную изменяя тесты.

Есть какие-нибудь мысли?

Answer 1

Если вы используете NUnit (что вам и следует), вам нужно будет создать новый метод тестирования для каждого из ваших текущих методов тестирования.NUnit использует отражение для запроса тестового класса на наличие методов, помеченных [Test] атрибут, с помощью которого он создает свой список тестов, отображаемых в пользовательском интерфейсе, а тестовые классы используют NUnit Assert метод, указывающий, прошли они или потерпели неудачу.

Мне кажется, что если бы ваши методы тестирования были такими последовательными, как вы говорите, все эти методы NUnit выглядели бы примерно так:

[Test]
public void MyTest()
{
   string msg;
   bool result = OldTestClass.MyTest(out msg);
   if (!result)
   {
      Console.WriteLine(msg);
   }
   Assert.AreEqual(result, true);

}

Как только вы заставите это работать, ваш следующий шаг - написать программу, которая использует отражение для получения всех имен методов тестирования в вашем старом тестовом классе и создает файл .cs, содержащий метод NUnit для каждого из ваших исходных методов тестирования.

Раздражает, может быть, но не очень болезненно.И вам нужно будет сделать это только один раз.

Answer 2

Вы вот-вот столкнетесь с идиомой "Унция профилактики стоит фунта лечения".Это особенно верно в программировании.

Вы не упоминаете о NUnit (который, я думаю, был куплен Microsoft в 2008 году, но не держите меня за это).Есть ли какая-то конкретная причина, по которой вы не просто использовали NUnit в первую очередь?