Первый опыт с открытым исходным кодом
На прошлой неделе у меня была первая возможность поработать над проектом с открытым исходным кодом в Школе программного обеспечения и дизайна Тьюринга. Сначала я нервничал, но, войдя в кодовую базу со знакомыми мне технологиями, я почувствовал себя намного комфортнее. Проект, над которым мы работали с группой коллег, был Wiki Education Dashboard. Это некоммерческая программа, реализуемая Wiki Education Foundation, которая способствует интеграции Википедии в курсовые работы в различных школах.
Проблема, которую мы решили решить, заключалась в обновлении их набора тестов, Enzyme, до версии 3.1.0. Последняя версия Enzyme теперь требует дополнительной настройки с помощью адаптера для правильной работы Enzyme. Поскольку наша группа имела опыт тестирования приложений React, мы решили принять вызов. Установка потребовала времени, так как многие технологии, используемые в приложении, были для нас новыми, но мы смогли запустить его к концу утра.
После запуска приложения мы обновили Enzyme до версии 3 и запустили их набор тестов. 21 тест не прошел из-за отсутствия конфигурации. Проведя небольшое исследование, мы обнаружили, что существует большая разница в настройке для запуска тестов. Раньше настройка выглядела так:
Настройка новой версии Enzyme теперь выглядит следующим образом:
Мы добавили эту конфигурацию в их файл testHelper, а также добавили еще две зависимости в их package.json. Одной из установленных зависимостей была энзим-адаптер-реакция-15 версии 1.0.2. Также есть адаптер для React 16, но поскольку приложение все еще было на версии 15, мы выбрали этот адаптер. Другая добавленная нами зависимость - это react-test-renderer, версия 15.6.2. Эта зависимость помогла при тестировании, отображая компоненты как чистые объекты Javascript. При повторном запуске тестов количество неудачных тестов увеличилось с 21 до 3, просто добавив конфигурацию и установив две зависимости! Это была огромная победа для нас, и мы были очень взволнованы, получив цифру 0. Мы продолжили и посмотрели на оставшиеся три теста.
Два из трех оставшихся тестов были очень похожи и выглядели так:
Проблема в том, что свойство узлов считается частной собственностью на «оболочке» Enzyme. В последней версии Enzyme эти частные свойства, включая .node, .nodes, .renderer, .root и .options, больше не доступны для Enzyme «shallow» и «mount». Новый способ получить доступ к той же информации - использовать метод getElements (). Теперь тест выглядел так:
Стоит упомянуть, что при наличии нескольких узлов число не передается через метод. Чтобы получить доступ к конкретному узлу, номер должен быть указан после метода, такого как «getElements () [0]».
После исправления обоих тестов нам нужно было исправить еще один тест. В этом тесте была аналогичная проблема в том, что он использовал узел вместо узлов, что, как упоминалось ранее, является еще одним частным свойством, которое также больше не доступно для «мелкого» и «монтирования». Тест на предыдущей версии Enzyme выглядел так:
Сначала мы попытались использовать тот же метод getElements (). Однако вскоре мы обнаружили, что этот метод был полезен только при наличии нескольких узлов. Вместо этого нам пришлось использовать метод .instance (), чтобы получить ту же информацию. Потребовалось немного покопаться, чтобы выяснить, что сработает в этом случае, но в конце концов мы наткнулись на эту статью, где у автора также была похожая ситуация. Мы изменили код, включив метод .instance (), и, наконец, разрешили последний неработающий тест:
После того, как мы решили проблемы, мы нашли время, чтобы объяснить, что мы сделали, чтобы решить тесты для новой версии Enzyme в нашем запросе на вытягивание. В этот запрос на перенос мы включили проблему, которую мы решили, дополнительные зависимости, которые мы установили, новую конфигурацию, которую мы добавили в их файл testHelper, и то, как мы обновили тесты, заменив любые ссылки на .nodes на .getElements () и .node с .instance (). Для справки в будущем, если вы новичок в отправке запросов на включение в проект с открытым исходным кодом, вот изображение того, как это может выглядеть:
Мы были рады завершить и объединить наш самый первый запрос на перенос с проектом с открытым исходным кодом. К сожалению, перед объединением нашего вклада у нас возникла одна небольшая проблема. При попытке слияния все тесты не проходили Travis CI. Причина, по которой это произошло, заключалась в том, что наша команда забыла установить пряжу. Yarn похожа на npm в том, что создает файл yarn.lock, который похож на файл package.json. Однако Yarn отличается тем, что использует детерминированный алгоритм, который строит все дерево зависимостей перед размещением файлов там, где они должны быть. Важная информация хранится в файле yarn.lock, поэтому ее можно использовать в каждой системе, устанавливающей зависимости. По сути, это сводится к тому, что Yarn гарантирует, что процесс установки одинаков на всех машинах, отслеживая гораздо больше информации, чем файл package.json. После установки пряжи и ее запуска на наших машинах мы снова смогли отправить запрос на перенос. На этот раз он прошел Travis CI и был успешно объединен с исходным кодом WikiEDU Dashboard.
Это давало возможность работать над этим проектом и вносить свой вклад в такое важное приложение. Также было повышением уверенности в том, что я могу внести свой вклад в огромную кодовую базу. Практика, которую Тьюринг предложил при тестировании, также оказалась невероятно полезной, и я чувствую себя гораздо увереннее при тестировании разработки Frontend. Я думаю, что важно знать, что, погружаясь в свои первые несколько идей с открытым исходным кодом, постарайтесь внести свой вклад в технологии, которые вы знаете. Вам будет удобнее работать с кодом, и, следовательно, вы будете лучше справляться с работой. При настройке внимательно следуйте инструкциям и часто общайтесь с разработчиками проекта. Не бойтесь спросить, если вы не до конца понимаете суть проблемы. Правильный вопрос часто может привести к правильному ответу.
