Поблочное тестирование: как получить доступ к текстовому файлу?
Я не попробовал это, но Вы могли попытаться к , публикуют Ваши формы доступа как веб-страницы доступа к данным к чему-то как sharepoint или так же, как веб-страницы и затем используют инструмент такой в качестве селен для управления браузером с комплектом тестов.
, Очевидно, это не столь идеально как управление кодом непосредственно через модульные тесты, но это может получить Вас часть пути. удача
4 ответа
Вы должны добавить атрибут DeploymentItem в свой тестовый класс. С помощью этого атрибута вы указываете файлы, которые копируются в выходной каталог для тестового запуска.
Например:
[TestMethod]
[DeploymentItem(@"myfile.txt", "optionalOutFolder")]
public void MyTest()
{
...
}
См. Также: http://msdn.microsoft.com/en-us/library/ ms182475.aspx .
Я не могу ответить на ваш вопрос, так как не использую MSTest. Однако я бы подумал, является ли доступ к файловой системе в модульном тесте правильным. Если вы введете зависимость от файловой системы, тест станет медленнее и менее надежным (теперь вы зависите от чего-то, чего может не быть / доступного / и т. Д.). Именно по этим причинам многие люди скажут: «Это не модульный тест, если он попадает в файловую систему».
Хотя это не жесткое правило, его всегда стоит учитывать. Каждый раз, когда мне приходится касаться файловой системы в тестах, я стараюсь избегать этого, потому что считаю, что тесты, основанные на файлах, труднее поддерживать и, как правило, менее согласованы.
Я бы рассмотрел абстрагирование файловых операций в некоторой степени. Здесь вы можете делать множество вещей, от изменения внутренней стратегии загрузки (посредством внедрения зависимостей) до - даже лучше - разделения загрузки / использования файла, чтобы потребителю содержимого файла не приходилось даже заботиться о загрузке стратегия.
Когда мне нужен кусок текста как часть модульного теста, а он больше одной или двух строк, я использую встроенный ресурс . Это не загромождает ваш тестовый код, потому что это отдельный текстовый файл в исходном коде. Он компилируется прямо в сборку, поэтому вам не нужно беспокоиться о копировании в отдельный файл после компиляции. Ваш тестируемый объект может принимать TextReader, и вы передаете StreamReader, который получаете при загрузке встроенного ресурса.
Как вы проводите тесты?
Мы используем (TestDriven.net -> Выполнить тесты).
По моему опыту, некоторые программы запуска тестов (например, Junit в Netbeans) не будут автоматически копировать какие-либо дополнительные текстовые файлы, которые могут вам понадобиться для тестирования. Так что в вашем случае вам, возможно, придется выполнить полную сборку, а затем снова попробовать запустить тесты.
И правильный способ доступа к текстовым файлам из тестов - это то, как вы пытаетесь это сделать. (Установка файлов «всегда копировать» и «содержимое» и доступ к ним из скомпилированного каталога).
Кроме того, не знаю, откуда люди приходят к выводу, что тесты, основанные на файлах, - это плохо. Это не так.
Во всяком случае, наличие отдельных тестовых файлов только очистит ваши тесты и сделает их более читаемыми. Рассмотрим некоторый метод синтаксического анализа xml, который возвращает большую строку:
String expectedOutput = fileOperator.ReadStringFromFile("expectedFileContents.xml");
String result = systemUnderTest.Parse(somethingtoparse);
Assert.Equals(expectedOutput, result);
Представьте, что если бы вывод был длиной 30 строк, не загромождали бы вы свой тестовый код одной гигантской строкой? или просто прочтите его из файла.