Есть некоторые вещи, которые вы просто не можете проверить?

Question

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

Если у нас есть класс, который напрямую зависит от .NET Framework, то есть от класса System.IO.File, тогда мы не можем проверить его изолированно.

Конечно, мы можем обернуть его и ввести в зависимый класс, но затем мы начинаем обертывать каждый класс .NET! Что делать, если эта обертка не является прямым вызовом? Возможно, сначала он выполняет некоторую проверку/бизнес-логику, которую вы хотите протестировать?

В настоящее время мы обертываем до определенного уровня, а затем просто не пытаемся тестировать эту оболочку. Возможно, это нормально, потому что он будет протестирован позже путем интеграции и исследовательского тестирования?

Вот пример в C# просто чтобы проиллюстрировать мою точку зрения:

Этот класс тесно связан с .NET Framework .. то отлично, но теперь я не могу проверить его в изоляции, она требует файлов существовать и т.д. .

public class PathResolver 
{ 
    public string Resolve(string filename) 
    { 
     string completePath = string.Empty; 
     if(!File.Exists(filename)) 
     { 
      return Path.Combine(@"D:\MyExample", filename); 
     } 
     return completePath; 
    } 
} 

мы можем модульное тестирование это, делая что-то вроде:

public class PathResolver 
{ 
    private readonly IFileSystem _fileSystem; 

    public PathResolver(IFileSystem fileSystem) 
    { 
     _fileSystem = fileSystem; 
    } 

    public string Resolve(string filename) 
    { 
     string completePath = string.Empty; 
     if(!_fileSystem.Exists(filename)) 
     { 
      return _fileSystem.Combine(@"D:\MyExample", filename); 
     } 
     return completePath; 
    } 
} 

Но теперь мы не можем проверить класс "Filesystem"!

Что представляют собой мысли других народов?

Answer 1

Действительно, в какой-то момент вам придется реализовать интерфейсы, такие как IFileSystem, тем самым приклеивая ваше приложение к платформе .NET. Этот «клей-код-в-промежутке» не может быть проверен модулем. Это не проблема, поскольку код клея очень прост.

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

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

Answer 2

В целом, тестирование фреймворков, таких как .NET, не является вашей ответственностью, это ответственность людей, освобождающих рамки.

Answer 3

Вы хотите проверить System.IO? Если нет, почему бы не использовать насмешливый/заглушающий подход, чтобы избавиться от зависимости?

Answer 4

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

Answer 5

К сожалению, вы не можете проверить все в приложении при модульном тестировании. Вот почему при тестировании вы хотите, чтобы ваши тесты занимали 90% кода над проектом.

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

Answer 6

Это не обязательно незавершенного вашим зависимости от всей структуры - только те части, которые препятствуют вашей способности тестировать ваш код. Поэтому я думаю, что вы должны быть свободны, чтобы отключить операции System.IO.File, а также вызовы базы данных. Мне также очень полезно иметь интерфейс IClock, чтобы указывать время, а не называть DateTime.UtcNow - это позволяет нам контролировать время прохождения модульных тестов.

Answer 7

Вам нужно всего лишь протестировать свой класс, а не рамки ниже.

Для этого вам понадобится testdriver, который устанавливает тестовый файл, в вашем примере создайте файл для разрешения, создайте экземпляр класса и дайте ему выполнить его работу.

Хороший testdriver также очищает тестовый сценарий и оставляет систему в том же состоянии, что и перед тестом.

Answer 8

Если вы не можете протестировать класс, но вы можете издеваться над ним, используя изоляционную структуру (Rhino Mocks, Typemock, Moq), вы можете обмануть детали этого «неустойчивого» класса.

Answer 9

Это прекрасный пример разницы между тестированием модулей и интеграционным тестированием. Для модульного тестирования вашего PathResolver вам необходимо передать макет объекта, созданного вручную, или используя фреймворк (например, мой любимый Moq). Используя макет объекта, вы сможете проверить, вызван ли метод Combine.

Тест блок будет выглядеть следующим образом (с помощью Moq):

[Test] 
public void ShouldCombinePath() 
{ 
    IFileSystem fs = new Mock<IFileSystem>(); 

    PathResolver resolver = new PathResolver(fs.Object); 

    resolver.Resolve("Test.filename"); 

    fs.Verify(fs => fs.Combine()); 
} 

испытания блока должны быть выполнены быстро, без внешних зависимостей. Их следует вызывать на каждом компиляторе.

Но вы правы, вам все равно нужно проверить конкретный класс. Это то, что мы называем интеграционным тестированием. Я предлагаю вам создать отдельный проект под названием «MyProject.IntegrationTest» и протестировать SystemFileSystem напрямую, используя тестовые файлы, включенные в проект.

Тест интеграции должен выглядеть так

[Test] 
public void ShouldCombinePath() 
{ 
    DotNetFileSystem fileSystem = new DotNetFileSystem(); 

    string resultPath = fileSystem.Combine("Test.filename"); 

    Assert.That(resultPath, Text.Contains("@D:\MyExample\Test.filename")); 
} 

интеграционные тесты, как правило, называют при создании сборки программного обеспечения на новый коммит, используя непрерывную программу интеграции. Они могут быть медленными, потому что они используют внешние зависимости.