Должны ли быть модульные тесты для сложных регулярных выражений?

Должен ли я написать модульные тесты для сложных регулярных выражений в моем приложении?

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

РЕДАКТИРОВАТЬ:

Я согласен с Доком Брауном, который в своем комментарии отмечает, что это особый случай модульного тестирования внутренних компонентов .

Но в качестве внутренних компонентов регулярные выражения имеют несколько особых характеристик:

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

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

Regex может быть мощным инструментом, но это не тот инструмент, которому можно доверять, просто продолжая работать, если вы вносите даже незначительные изменения в сложные регулярные выражения.

Поэтому создайте множество тестов, которые документируют случаи, которые он должен охватывать. И создайте множество тестов, которые документируют случаи, в которых он должен потерпеть неудачу, если он используется для проверки.

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

Если бы я был в организации, которая вообще не использовала модульные тесты, я все равно написал бы тестовую программу, которая проверяла бы любое регулярное выражение, которое мы использовали бы. Я бы даже сделал это в свое свободное время, если бы пришлось, мои волосы больше не должны терять цвет.

Регулярные выражения - это код вместе с остальной частью вашего приложения. Вы должны проверить, что код в целом выполняет то, что вы ожидаете. Это имеет несколько целей:

• Тестовая документация. Это ясно демонстрирует, что вам нужно сделать код. Если это проверено, это важно.
• Будущие сопровождающие могут быть уверены, что, если они изменят его, тесты будут гарантировать, что поведение не изменится.

Поскольку при использовании кода на другом языке, встроенном вместе с остальным, возникает дополнительное препятствие, вам, скорее всего, следует уделить этому дополнительное внимание в интересах обслуживания.

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

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

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

Я думаю, что с этим вы ответили сами. Регулярные выражения в модуле, скорее всего, являются деталями реализации.

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

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

Если вам нужно спросить, ответ - да.

Предположим, что приходит какой-то FNG и думает, что он может «улучшить» ваше регулярное выражение. Теперь он FNG, поэтому автоматически идиот. Именно тот человек, который никогда не должен трогать ваш драгоценный код ни при каких обстоятельствах! Но, возможно, он имеет отношение к PHB или что-то, так что вы ничего не можете сделать.

За исключением того, что вы знаете, что PHB заставит вас пнуть и кричать обратно в этот проект, чтобы «возможно, дать парню несколько советов о том, как вы устроили этот беспорядок», когда все идет плохо. Таким образом, вы записываете все случаи, которые вы тщательно рассмотрели при создании своего прекрасного шедевра выражения.

И так как вы записали их все, у вас есть две трети пути к набору тестовых случаев, поскольку - давайте посмотрим правде в глаза - тестовые примеры regex очень легко запустить после того, как вы построили среду.

Итак, теперь у вас есть набор граничных условий, альтернатив и ожидаемых результатов. И вдруг тестовые примеры - это документация, как и обещано во всех этих слишком гибких постах в блоге. Вы просто указываете FNG, что, если его «улучшение» не пройдет существующие тестовые случаи, это не будет большим улучшением, не так ли? И где его предлагаемые новые тестовые примеры, которые демонстрируют некоторую проблему с исходным кодом, который, поскольку он работает, ему не нужно изменять, никогда !!!