Как обрабатывать большие строки в модульных тестах? - PullRequest
4 голосов
/ 20 января 2009

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

Теперь возникают некоторые проблемы:

  • Как включить тестовую строку в \ n, \ r, \ t, umlauts и т. Д.?
  • Как установить кодировку?
  • Должен ли я использовать внешние файлы, открываемые FileInputStream? (слишком много накладных расходов, imho)

Итак ... каковы ваши подходы к решению этой проблемы?

Ответы [ 5 ]

2 голосов
/ 20 января 2009

Для больших строк я бы использовал файлы. Производительность достаточно высока для юнит-тестов. Для этого небольшого компромисса вы:

  1. Не нужно беспокоиться о экранировании символов
  2. Может различать содержимое в управлении исходным кодом
  3. Может проверять документы самостоятельно (например, xml / html)
2 голосов
/ 20 января 2009

Как включить тестовую строку в \ n, \ r, \ t, umlauts и т. Д.?

Хм ... просто напишите, как хотите? Вы можете использовать \ n, \ r и \ t, umlauts stc. в Java строковые литералы; если вас беспокоит кодировка файла исходного кода, вы можете использовать escape-последовательности Unicode и создавать их с помощью инструмента native2ascii, поставляемого с JDK.

Как установить кодировку?

Когда у вас есть Java String, уже слишком поздно беспокоиться о кодировках - они используют UTF-16, и возникают любые проблемы с кодированием при переводе между строками и байтовыми массивами (в отличие от C, Java четко разделяет эти понятия)

Edit: Если ваши строки слишком велики, чтобы их можно было удобно использовать в исходном коде, или вы действительно беспокоитесь об обработке разрывов строк и пробелов, то лучше всего хранить каждую строку в отдельном файле; в этом случае кодировка должна быть указана при чтении файла (в конструкторе InputStreamReader)

2 голосов
/ 20 января 2009
  • Если у вас их много, храните тестовые строки в отдельном классе со строковыми символами
  • Старайтесь не хранить файлы на диске, если это не нужно. Я согласен с вашей претензией - это приводит к чрезмерным накладным расходам (не говоря уже о том, что произойдет, если вы начнете получать ошибки ввода-вывода)
  • Убедитесь, что вы тестируете строки с разными переносами строк (\n, \r\n, \r\n\r) для разных ОС
1 голос
/ 20 января 2009

Вы можете использовать язык сценариев для кодирования ваших тестов.

JRuby и Groovy поддерживают ЗДЕСЬ документы, облегчающие определение большой строки, которая занимает несколько строк

# In JRuby
mystring = <<EOS
This is a long string that
spans multiple lines.
EOS

# In Groovy
def mystring = """This is a long string that
spans multiple lines."""

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

0 голосов
/ 20 января 2009

Если вы постоянно используете символы, которые трудно выразить в литеральных строках (например, ", \, символы не в [ -~]), то вы можете рассмотреть возможность быстрого поиска и замены строка перед ее использованием. Например, если вы используете \ много, то вы можете написать функцию для обмена \ и /. Вы можете использовать многосимвольную последовательность для представления акцентированных символов.

Однако существует очевидная опасность в конечном итоге найти решение, несоразмерное с проблемой. Иногда \u#### просто проще.

Если вы собираетесь использовать файлы, отличные от Java, я предлагаю открывать их как ресурсы (Class.getResourceAsStream / getResource), а не как свободные файлы.

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