Хотя вы можете использовать определенные средства форматирования для преобразования и встраивания любого текстового файла или длинного литерала в виде строки Java (например, с разрывами строк, необходимыми экранами и т. д.), я не могу вспомнить частые ситуации, когда вам понадобятся эти возможности. .
Тенденция в программном обеспечении, как правило, заключается в отделении кода от данных, с которыми он работает. Большие текстовые разделы, даже если они предназначены только для отображения или сравнения, являются данными и поэтому обычно хранятся во внешнем хранилище. Стоимость чтения файла (или даже кэширования результата в памяти) довольно низкая. Интернационализация проще. Менять проще. Контроль версий проще. Можно легко использовать и другие инструменты (например, средства проверки орфографии).
Я согласен, что в случае модульных тестов, когда вы хотите сравнить вещи с макетом, вам потребуются крупномасштабные сравнения текста. Однако, когда вы имеете дело с такими большими файлами, у вас обычно будут тесты, которые могут работать с несколькими различными большими входными данными для получения нескольких больших выходных данных, так почему бы просто не загружать тестом соответствующие файлы, а не встраивать их?
То же самое и с XML. На самом деле, для XML я бы сказал, что во многих случаях вы захотите прочитать XML и построить дерево DOM, которое затем будете сравнивать, а не выполнять сравнение текста, на которое могут повлиять пробелы. И вручную создавать XML-дерево в вашем модульном тесте некрасиво.
person
Uri
schedule
23.04.2009