Порівняння текстів

Навіщо це в роботі

Порівняти дві версії конфігу, дві відповіді API, .env.example з робочим .env, вивід тесту «очікувано / отримано» - усе це задачі на кілька секунд, якщо різницю видно, і на кілька хвилин уважного читання, якщо ні.

Порівняння відбувається у вашому браузері: тексти нікуди не надсилаються, тож сюди можна вставляти й робочі конфіги.

Як це працює

В основі - класичний алгоритм найдовшої спільної підпослідовності (LCS). Він знаходить максимальний набір рядків, які збіглися в обох текстах у тому самому порядку, а все інше позначає як додане чи вилучене.

Той самий алгоритм лежить в основі git diff і diff у Unix - різниця лише в оптимізаціях для великих файлів. Тут порівняння порядкове, тому зміна одного символу показується як вилучений рядок плюс доданий.

Типові застосування в Laravel

.env.example проти .env - найчастіший випадок. Після git pull у прикладі з'явилися нові ключі, а в робочому файлі їх немає, і застосунок падає з незрозумілою помилкою.

# Те саме в терміналі, якщо зручніше
diff <(sort .env.example) <(sort .env)

Два composer.lock - зрозуміти, що саме оновилося після composer update.

Відповіді API до і після зміни - переконатися, що рефакторинг не змінив контракт.

Очікуваний і фактичний результат тесту. Pest показує різницю сам, але коли значення велике, зручніше подивитися на нього цілком:

expect($response->json())->toEqual($expected);

Обмеження

Порівняння порядкове, не посимвольне. Якщо в рядку змінилося одне слово, ви побачите весь рядок двічі - як вилучений і як доданий. Для конфігів і JSON це нормально, для суцільного тексту абзацами - незручно.

Мінімізований JSON чи CSS в одному рядку порівнювати марно: весь файл буде одним рядком. Спершу відформатуйте його - для JSON у нас є форматування, для SQL - своє.

Дуже великі тексти обмежені: LCS має квадратичну складність, і на десятках тисяч рядків браузер просто зупиниться. Для таких обсягів є git diff і diff у терміналі.