Модульное тестирование: как получить доступ к текстовому файлу? - PullRequest
30 голосов
/ 26 ноября 2009

Я использую Visual Studio 2008 с инструментами тестирования Microsoft. Мне нужно получить доступ к текстовому файлу из модульного теста.

Я уже настроил файл с действием сборки, установленным на «Содержимое», и скопировал в выходной каталог в «Всегда копировать», но файл не копируется в выходной каталог, который согласно System.Environment.CurrentDirectory равен * 1004. *

'{project_path} \ TestResults \ Pablo_COMPU 2009-11-26 15_01_23 \ Out'

Эта папка содержит все зависимости DLL проекта, но моего текстового файла там нет.

Как правильно получить доступ к текстовому файлу из модульного теста?

Ответы [ 5 ]

41 голосов
/ 26 ноября 2009

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

Например:

[TestMethod]
[DeploymentItem(@"myfile.txt", "optionalOutFolder")]
public void MyTest()
{
    ...
}

Смотри также: http://msdn.microsoft.com/en-us/library/ms182475.aspx.

11 голосов
/ 14 января 2012

В качестве альтернативы, если вы установите для всех ваших текстовых файлов значение «Копировать в каталог для сборки», вы можете указать их путь в своих тестах, выполнив это

var directory = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);
var path = string.Format("{0}\\{1}",directory,"myFile.txt");
4 голосов
/ 29 ноября 2009

Когда мне нужен фрагмент текста как часть модульного теста, а это больше, чем строка или две, я использую встроенный ресурс . Он не загромождает ваш тестовый код, потому что это отдельный текстовый файл в исходном коде. Он компилируется прямо в сборку, поэтому вам не нужно беспокоиться о копировании в отдельный файл после компиляции. Тестируемый объект может принять TextReader, и вы передаете StreamReader, полученный при загрузке встроенного ресурса.

3 голосов
/ 26 ноября 2009

Я не могу ответить на ваш вопрос, так как я не использую MSTest. Однако я хотел бы рассмотреть вопрос о том, является ли доступ к файловой системе в модульном тесте правильным решением. Если вы введете зависимость от файловой системы, тест станет медленнее и менее надежным (теперь вы зависите от чего-то, чего там может не быть / доступно / и т. Д.). Именно по этим причинам многие люди скажут: «Это не модульный тест, если он попадает в файловую систему».

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

Я бы рассмотрел абстрагирование файловых операций до некоторой степени. Здесь вы можете сделать множество вещей, от изменения внутренней стратегии загрузки (с помощью Dependency Injection) до - еще лучше - разделения загрузки / использования файла, чтобы потребителю содержимого файла даже не пришлось забота о стратегии загрузки.

0 голосов
/ 26 ноября 2009

Как вы проводите свои тесты?

Мы используем (TestDriven.net -> Run Tests).

По моему опыту, некоторые участники тестирования (например, Junit в Netbeans) не будут автоматически копировать любые дополнительные текстовые файлы, которые могут вам понадобиться для тестирования. Так что в вашем случае вам, возможно, придется выполнить полную сборку, а затем снова попробовать запустить тесты.

И правильный способ доступа к текстовым файлам из тестов - это способ, которым вы пытаетесь это сделать. (Настройка файлов на «всегда копировать» и «содержимое» и доступ к ним из скомпилированного каталога).

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

Во всяком случае, имея отдельные тестовые файлы, только очистит ваши тесты и сделает их более читабельными. Рассмотрим метод анализа XML, который возвращает большую строку:

String expectedOutput = fileOperator.ReadStringFromFile("expectedFileContents.xml");
String result = systemUnderTest.Parse(somethingtoparse);
Assert.Equals(expectedOutput, result);

Представьте себе, если бы вывод был длиной в 30 строк, вы бы загромождали свой тестовый код одной гигантской строкой? или просто прочитайте это из файла.

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