Надлежащее поблочное тестирование: тестирование метода без [доступного] или возвращаемого значения состояния

Основные методы, как предполагается, являются очень тонкими и просто сдвинулись с мертвой точки. Следовательно обычно не протестированный. например, приложение .net Winforms Основной метод может содержать

static void Main()
{
  Application.EnableVisualStyles();
  Application.SetCompatibleTextRenderingDefault(false);
  Application.Run(new MainWindow());
}

Если Ваш основной метод делает много материала, рассмотрите извлечение метода (к новому классу в случае необходимости). например, как показано ниже... (не имеют JavaIDE удобным.. foll код .NET должно быть легко перевести),

static void Main()
{
  new MainApp().Run();
}

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

public class MainApp
{
  private Server m_Server;
  public MainApp():this(new Server())
  {}
  public MainApp(Server s)
  {  m_Server = s;      }

  public void Run()
  {  Log(LaunchServer());  }

  private string LaunchServer()
  {  return (m_Server.start() ? "started" : "failed");        }

  protected virtual void Log(string sMessage)
  {  System.Console.WriteLine(sMessage);        }
}

Теперь позволяет взгляду на тестовый код... Я буду использовать "подкласс и переопределять" прием для кэширования результата как показано ниже. (Вы могли также использовать Насмешки.. согласно вкусу)

public class FakeApp : MainApp
{
  private string sLastLoggedMessage;

  public FakeApp(Server s) : base(s) { }

  public string getLastLoggedMessage()
  {  return sLastLoggedMessage;        }

  protected override void Log(string sMessage)
  {  sLastLoggedMessage = sMessage;        }
}

тест теперь тривиален

[TestFixture]
public class TestMainApp
{
  [Test]
  public void TestRun()
  {
    Server s = new Server();
    FakeApp f = new FakeApp(s);

    f.Run();

    Assert.AreEqual("started", f.getLastLoggedMessage());
  }
}

если Вы не можете вынудить Server.start () успешно выполниться или перестать работать согласно Вашему требованию.. Можно создать FakeServer.. подкласс и переопределение начинают () возвращать фиксированные значения.

Если метод делает что-то, он может быть протестирован. Если это не делает, это должно прекратить существование. Осуществите рефакторинг его далеко. HTH

Вы (обычно) не делаете основного теста единицы () методы. В Вашем случае Вы модульный тест класс Сервера (и вероятно другие) т.е. тестирование это - открытый интерфейс.

Так как Ваш метод имеет информационный поток только в одном направлении - к объектам сотрудника (в этом примере: Серверный объект), и иначе не возвращает значения или выдает исключения, Вы могли предоставить ложный объект сотрудника (ложный Сервер в Вашем примере), который настроит ожидания о вызовах метода и их параметрах, полученных от Вашего основного () метод.

Можно использовать одну из нескольких платформ фиктивного объекта для этого, например, Easymock.

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

Конечно, для предоставления фиктивного объекта, необходимо было бы изменить метод немного относительно объектного инстанцирования - делают "Сервер" интерфейсом, не реальным классом, и используют платформу (как Spring) вместо того, чтобы вручную инстанцировать Серверный объекта, например, вместо:

Server myServer = new Server();

у Вас было бы это:

Server myServer = applicationContext.getBean("server");

Вы создали бы отдельные конфигурации контекста приложения Spring для производственного приложения и для модульных тестов, и различие будет то, что контекст приложения для производства был бы настроен с помощью XML-файла, в то время как для модульных тестов будет программно создан и заполнен с фиктивными объектами от тестовой установки классов () методы.

Если требуется иметь этот случай - и многих других - разрешенный, я могу предложить серию Pragmatic Unit Testing?

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

перенесите код в неосновной метод и тест это ;-)

серьезно, что все остальные сказали

но если необходимо... заставить модульный тест запустить консольное приложение в оболочке DOS (см. объект Процесса) с STDOUT, перенаправленным в файл, затем считайте содержание выходного файла, чтобы видеть, "запустился" ли, как это говорит ", или "перестал работать", какой бы ни Вы ожидаете