Как разработчик, программное обеспечение с открытым исходным кодом лежит в основе большей части того, что я делаю. Практически все инструменты, которые я использую ежедневно, имеют открытый исходный код или созданы на платформах с открытым исходным кодом. Удивительно, как много я должен этим проектам, и как много я беру от них, не возвращая. Так что же я сделал? Я решил найти проект с открытым исходным кодом и внести свой вклад! Поскольку это был мой первый раз, я объединился с двумя друзьями, которые тоже хотели сделать свои первые шаги в работе над открытым исходным кодом.
Поиск проекта
После просмотра ряда проектов на Github мы решили внести свой вклад в репозиторий GitPoint (https://github.com/gitpoint/git-point). GitPoint — это мобильное приложение для GitHub, самопровозглашенное как Github в вашем кармане. Он построен на React Native и использует GitHub API, оба из которых у нас есть. Что меня впечатлило в GitPoint, так это:
1) Он поддерживается в хорошем состоянии, над ним работает активное сообщество, включая активный канал Gitter и множество открытых вопросов, которые были помечены как доступные для первого участника.
2) У него есть четкая документация для вкладов, а также четкие рекомендации по стилю кода, тестирования и фиксации, что упрощает переход и выполнение работы, которая действительно будет полезна для проекта.
Подготовка
После того, как проект был решен, первым шагом стала настройка нашей среды. Мы клонировали репозиторий, следуя рекомендациям, которые они предоставили, и довольно быстро заработали. У меня был небольшой опыт работы с React Native, но никоим образом не считаю себя экспертом. Наличие подробных инструкций по настройке среды, особенно при работе с кодом, над которым я никогда раньше не работал, было чрезвычайно полезным. Разговаривая с другими друзьями, у которых был опыт работы над другими проектами с открытым исходным кодом, я знаю, что не каждый проект так хорошо документирован, а когда это не так, копание в устаревшем коде и загадочных зависимостях может стать серьезной головной болью.
Над чем работать
После запуска среды приложения на наших компьютерах мы углубились в базу кода, обращая внимание на проблемы, отмеченные в репозитории как хорошие для новичков. Некоторые из них выглядели интересными, включая переход на стилизованные компоненты, ошибки пользовательского интерфейса, тестирование и добавление простых функций. Когда мы просмотрели компоненты и поняли, как устроено приложение, мы заметили, что в целом, хотя качество кода было стабильным, все было хорошо организовано и легко читалось, покрытие тестами было… не очень хорошим. Общий охват составил около 43%, большая часть которого была сосредоточена на тестировании компонентов и пользовательского интерфейса. Что действительно выделялось, так это их тестовое покрытие вызовов API, которое составляло 0%. Здорово! Я люблю тестировать! Давай сделаем это!
Приступая к тестированию, я знал, что для каждой функции вызова API нам нужны три основные области:
1) Он вызывает выборку с правильными параметрами
2) Он возвращает ожидаемые данные ответа
3) Он обрабатывает ошибки, как и ожидалось, если существует обработка ошибок.
Приступая к работе, прежде чем мы на самом деле написали какие-либо тесты, мы просмотрели поток функций в их файле вызовов API, чтобы убедиться, что мы действительно понимаем, как они строят свои вызовы. Первое, что бросилось в глаза, это то, что сами вызовы не обрабатывали ошибки, а это означало, что номер 3 отсутствовал. Круто, не то, что мы ожидали, но нужно писать меньше тестов. Мы также поняли, что функций было МНОГО, но они разделяли ответственность. На самом деле, большинство вызывало только три функции в файле, передавая им метод вызова, токен авторизации и частичный URL-адрес для построения параметров, а затем передавая эти параметры и URL-адрес функции call(). Зная, что у нас недостаточно времени для тестирования каждой отдельной функции, мы сосредоточились на этих нескольких основных функциях, поскольку это лучший способ обеспечить максимальное покрытие в наших тестах.
Следующим шагом было начать писать тесты. Мы быстро обнаружили, что обычный способ, которым мы тестировали вызовы API, имитируя window.fetch() и разрешая это в обещание, не будет работать, потому что window.fetch() требует, чтобы у нас был доступ к DOM. , а в React Native нет окна DOM браузера. К счастью, мы смогли обойти это с помощью global.fetch(). Как только мы поняли это, методом проб и ошибок копаясь в фиктивных данных API, которые уже были на месте для другого тестирования, мы смогли добиться значительного прогресса.
После того, как мы написали наши тесты, пришло время представить наш PR. Не зная, как будут приняты тесты (но получив одобрение от других активных участников), и не имея других подобных тестов, на которых можно было бы основывать наш стиль кода, мы прочесали то, что мы написали, чтобы убедиться, что то, что мы написали, было правильным. чистый и последовательный, а затем тщательно составленный наш PR. К счастью, репозиторий предоставил шаблон PR, поэтому мы отправили его вместе с более подробной информацией о том, что мы сделали, надеясь, что наши усилия будут одобрены. Когда мы проверили на следующий день, он был успешно слит, и мы увеличили общее тестовое покрытие на целых 2%!
