Недоступен ли доступ к файлам в модульных тестах?

Question

При написании модульных тестов, связанных с XML (например, тестируйте класс, который читает/генерирует XML), я использовал для записи утвержденных результатов XML-String/my input XML String в отдельных файлах рядом с моим модульным тестом. Предположим, у меня есть класс «MyTransformer», который преобразует один формат XML в другой. Тогда я хотел бы создать три файла все в одном пакете:

• MyTransformerTest.java
• MyTransformerTestSampleInput.xml
• MyTransformerTestExpectedOutput.xml

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

Reader transformed = MyTransformer.transform(getResourceAsStream("MyTransformerTestSampleInput.xml"))); 
Reader expected = getResourceAsStream("MyTransformerTestExpectedOutput.xml"); 
assertXMLEqual(expected, transformed); 

Однако коллега ague сказал мне, что доступ к файлу, который у меня есть в этом модульном тесте, неприемлем. Он предложил создать литеральную строчную константу (private static final String), содержащую мое содержимое XML-файла, возможно, в отдельном классе groovy из-за преимущества многострочных строк, а не для записи файла XML в файлы.

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

Как вы думаете? Действительно ли доступ к файлу плохой? Если да: почему? Если нет, то почему все нормально?

Answer 1

Две проблемы с файлами в модульных тестах:

• они замедляют цикл тестирования. У вас могут быть тысячи модульных тестов, которые, желательно, запускаются при каждой сборке, поэтому они должны быть как можно быстрее. Если вы можете ускорить их (например, избавившись от операций ввода-вывода), вы захотите это сделать. Разумеется, это не всегда возможно, поэтому вы обычно выделяете «медленные» тесты через NUnit [Category] или что-то подобное - и затем выполняйте эти специальные тесты реже - скажем, только на ночных сборках.
• вводятся дополнительные зависимости. Если для проверки требуется файл, он будет работать не только тогда, когда логика, лежащая в основе теста, неверна, но также и в случае отсутствия файла, либо у тестируемого бегуна нет разрешений на чтение и т. Д. Это делает отладку и исправление не очень приятными!

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

Answer 2

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

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

Вы действительно будете изолировать/подделать доступ к файлу и проверить поведение вашего кода (если есть), используя Unit Tests.Они быстрее и легче работать. Это дает вам точную обратную связь, если она написана правильно.

Answer 3

В этом случае у меня есть единичный тест, в котором используется внутреннее представление файла, которое в этом случае является строковым литералом.

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

Так что все это зависит от определений теста Unit/Integration. Оба являются действительными тестами, просто зависит, какой тест вы пишете в то время.