В эпизоде приключений с открытым исходным кодом на этой неделе мне было поручено исправить ошибки в анализе URL-адресов Brave Browser. Прежде всего, что такое Brave Browser? Это веб-браузер с открытым исходным кодом, который фокусируется на блокировке веб-трекеров и навязчивой рекламы. Это также поощряет конфиденциальность за счет меньшего обмена вашими личными данными с рекламными компаниями. Теперь, когда мы немного знаем о Brave Browser, что это значит для нас?
Brave Browser имеет открытый исходный код, что означает, что любой может получить доступ к кодовой базе, а также внести свой вклад. Поскольку это относительно новый браузер по сравнению, например, с Firefox и Chrome, в нем все еще есть несколько ошибок, особенно в анализе URL-адресов. Итак, мой профессор Дэвид Хамфри дал моему классу и мне несколько тестовых URL-адресов для тестирования в Brave Browser и сравнения его результатов с результатами в Chrome и Firefox. Большинство приведенных URL-адресов работали, кроме 2.
"https://www.google.ca/search?q=dog cat"" https://www.google.ca/search?q=dog cat "
Оба этих URL-адреса не были правильно проанализированы Brave. Результат этих URL-адресов можно увидеть ниже.
Как вы можете видеть, он берет весь URL-адрес и передает его в панель поиска, что определенно не то, что нам нужно. Мы хотим, чтобы он просто передал «dog cat» в строку поиска и получил для этого результаты. Причина такого плохого синтаксического анализа URL-адреса заключается в том, что Brave не учитывал пробелы в параметрах запроса URL-адреса. Если перед URL-адресом или после него есть начальные пробелы, Brave учитывает это, вызывая функцию trim().
Теперь самое интересное в этом исправлении ошибки заключается в том, что для его достижения был использован новый подход. Что это за новый метод? Это называется Test Driven Development или сокращенно TDD. Этот метод фокусируется на написании тестов ПЕРЕД исправлением ошибки, поэтому вместо этого мы фокусируемся на том, чтобы наши неудачные тесты прошли, а не наоборот.
Исходя из этого принципа, нам нужно сначала написать тесты. Как вы можете видеть ниже, это два теста, написанные для этого варианта использования.
Теперь пришло время проверить, не работают ли эти тесты так, как ожидалось. После установки библиотеки mocha с помощью npm install — global mocha и их сборки я запустил npm run test — — grep=”dog”, чтобы показать мне только те тесты, в которых есть слово dog. Это тогда показало мне 2 теста, которые потерпели неудачу.
Как вы можете видеть, ожидаемые значения были ложными, однако возвращаемые значения были истинными, что означает, что функция isNotUrl не считает эти 2 URL-адреса действительными из-за пробела между собакой и кошкой. Теперь, когда мы знаем, что тесты не работают, пришло время исправить их.
После поиска в кодовой базе стало ясно, что как только URL попадает в функцию isNotUrl, он обрезается. Поэтому в этой части кода нам нужно обработать любые пробелы, прежде чем произойдут более сложные манипуляции с URL. Я понял, что регулярное выражение — лучший способ справиться с неопределенным количеством пробелов, а также убедиться, что они не расположены в начале или в конце URL-адреса.
Как вы можете видеть, приведенное выше регулярное выражение просто говорит: «ищите все пробелы, которые не расположены в начале или в конце URL-адреса, и замените их на %20». Теперь это действительно работает? Да! Модульные тесты сейчас проходят.
Время проверить, исправляет ли он URL-адрес при поиске в Brave Browser.
Успех!!! В заключение, это исправление ошибки было очень важным, так как оно показало мне другой подход к исправлению ошибок. Вместо того, чтобы отлаживать код и создавать тесты постфактум, чтобы убедиться, что все работает хорошо, я могу создавать тесты, которые, как я знаю, сломаются, а затем идти и исправлять их. В общем, важный урок, извлеченный из этого исправления ошибки, и с нетерпением жду реализации этого подхода в будущих исправлениях ошибок! На данный момент это обертка. До встречи в следующем блоге!
