Php-imap: ВАЖНО: нам нужны модульные тесты для объединения запросов на вытягивание и закрытия проблем (нужна помощь)

+1 к этому проекту нужны модульные тесты, и если были модульные тесты, каждый патч должен включать дополнительные модульные тесты.

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

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

Эта проблема НЕ должна препятствовать объединению доступных исправлений

@ nickl- Простите, а вы хотите, чтобы я что-то слил без всяких тестов? А если будут еще баги? А как быть с обратной совместимостью?

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

возможно, пришло время подумать о добавлении дополнительных сопровождающих или даже о передаче проекта существующей команде, такой как Respect

@ nickl: Я не знаю Respect team и не хочу нести ответственность за их изменения. И я не понимаю, почему ребята из Respect team должны писать тесты для этой библиотеки? Они его не используют (как и я).
Вы, ребята, используете его, поэтому, если вы хотите, чтобы он был исправлен или расширен в этом репо, просто попробуйте написать несколько тестов. На самом деле это не имеет большого значения. В противном случае не стесняйтесь форкнуть его и сообщать обо всех проблемах по ссылке на ваше репо, чтобы пользователи могли опробовать вашу версию на свой страх и риск. Но, пожалуйста, не просите меня взять на себя ответственность за чей-то риск, выпуская что-то, что невозможно полностью протестировать.

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

Эта проблема НЕ должна препятствовать объединению доступных исправлений

Печально то, что 99% пользователей инструментов с открытым исходным кодом - это просто пользователи, они не вносят ничего ценного. Я не знаю, почему многие пользователи ожидают, что владельцы репозиториев ДОЛЖНЫ поддерживать свои проекты. Нет, не делаем. Я потратил в 100 раз больше времени на написание ядра этого инструмента, чем у всех, кто создавал pull request. Так вы думаете, что теперь я ДОЛЖЕН тратить свое время на тестирование запросов на включение, которые мне даже не нравятся? Но я даже этой библиотекой не пользуюсь, вообще-то она мне и не нужна. У меня есть еще 10 проектов, которые для меня гораздо важнее.

@barbushin Извини, что ты так себя чувствуешь, просто пытался помочь.

Я уверен, что говорю от имени каждого пользователя, когда говорю: Большое спасибо за ваши усилия, мы все очень ценим то, что вы сделали до сих пор, и вы определенно не обязаны делать что-то большее, чем вы готовы.

Автоматическое тестирование было бы здорово. Я вижу два варианта:

1. Выполните рефакторинг Mailbox::imap() чтобы не вызывать imap_* функции и чтобы их можно было высмеять.
2. Используйте реальный сервер IMAP, который содержит приспособления.

Вариант 1 не невозможен. На мой взгляд, проект Aura неплохо справляется с подделкой встроенных функций. Взгляните на Phpfunc в Aura.Session в качестве примера. Этот подход включает в себя некоторый рефакторинг перед внедрением модульных тестов. Конечно, этот процесс также может привести к появлению новых ошибок, и обратная совместимость не гарантируется.

Вариант 2 - это не модульное тестирование, а интеграционное тестирование. Преимущество состоит в том, что текущую кодовую базу можно протестировать как есть. Следовательно, можно будет проверить, внесет ли объединение запросов на вытягивание BC в текущую базу кода.
Однако тестовая установка довольно сложна: необходим IMAP-сервер, который «размещает» почтовые сообщения как фикстуры. На мой взгляд, такой подход к тестированию более полезен для этого проекта, и я могу внести свой вклад в тестовые примеры, опираясь на свой большой опыт в этом сценарии.

Какой подход ты предпочитаешь?

Как по мне, подход 2. выглядит как то, что нам нужно.

Затем нам понадобится док-контейнер с IMAP-сервером. Модульные тесты будут отправлять электронные письма на этот сервер с помощью функции PHP mail() или какой-либо другой библиотеки, а затем проверять ожидаемые результаты, обращаясь к нему с помощью php-imap.

Я проверил, есть несколько контейнеров докеров с серверами IMAP, а также я вижу, что Travis поддерживает контейнеры докеров.

Я согласен!

К сожалению, я никогда раньше не использовал Travis, и у меня мало опыта работы с Docker.

Тем не менее, я могу помочь вам написать несколько модульных тестов.

В эти выходные я попробую настроить Travis с сервером IMAP и несколькими примерами тестов. Будет новая ветка tests , поэтому вы можете использовать ее в качестве примера и делать запросы на вытягивание с вашими тестами.

Как там вообще дела с веткой tests или тестами PHPUnit? Вот хорошее объяснение того, как вы можете писать свои собственные тесты PHPUnit: https://www.youtube.com/watch?v=k9ak_rv9X0Y

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

Держи, @barbushin : PR # 292

Еще немного, но лучше, чем ничего. :)

Когда вы создаете новые запросы на слияние, убедитесь, что вы используете ветку develop качестве основы. :)

Travis CI интегрирован и работает. Существуют и тесты PHPUnit, но их необходимо расширить и улучшить.

Осталось всего 24 открытых вопроса и 1 запрос на перенос! Давайте решим и их. :)

@ Sebi94nbg Да благословит тебя Бог, чувак!

Осталось 12 выпусков! :)

С # 278 и # 306 мне нужна помощь. Это действительно отнимает много времени, и его сложно исправить или найти обходной путь.

@barbushin, не могли бы вы добавить php-imap в https://codeclimate.com/quality/? К сожалению, у меня нет на это разрешения.

@Дональд Трамп

https://codeclimate.com/github/barbushin/php-imap

[![Maintainability](https://api.codeclimate.com/v1/badges/02f72a4fd695cb7e2976/maintainability)](https://codeclimate.com/github/barbushin/php-imap/maintainability)

<a href="https://codeclimate.com/github/barbushin/php-imap/test_coverage"><img src="https://api.codeclimate.com/v1/badges/02f72a4fd695cb7e2976/test_coverage" /></a>

Спасибо, @barbushin! Я уже добавил эти значки в README: https://github.com/barbushin/php-imap/commit/ffee374e9f5b5867f12feb8b0096485a0780b103

К сожалению, я не могу ничего изменить на https://codeclimate.com/github/barbushin/php-imap, поскольку он говорит, что у меня нет разрешений. Итак, вам нужно будет настроить тестовое покрытие.

Я уже передал конфигурационный файл с проверками по умолчанию - возможно, его нужно обновить: https://github.com/barbushin/php-imap/commit/5c53833ea264a777ffbdd65e5e166dd3d21b5687

Вот идентификатор тестового репортера

4eed0d135b9e1a1668a68e5e29cc71faf872937d13c42efa4faf42dad5ed3375

См. Https://docs.codeclimate.com/docs/configuring-test-coverage

С уважением
Сергей Барбушин

В среду, 15 мая 2019 г., в 18:19 TS3tools [email protected] написал:

Спасибо, @barbushin https://github.com/barbushin ! Я уже добавил
эти значки в README: ffee374
https://github.com/barbushin/php-imap/commit/ffee374e9f5b5867f12feb8b0096485a0780b103

К сожалению, я не могу ничего изменить на
https://codeclimate.com/github/barbushin/php-imap, как говорится, что я
нет разрешений. Итак, вам нужно будет настроить тестовое покрытие.

Я уже передал конфигурационный файл с проверками по умолчанию - это может
необходимо обновить: 5c53833
https://github.com/barbushin/php-imap/commit/5c53833ea264a777ffbdd65e5e166dd3d21b5687

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/barbushin/php-imap/issues/286?email_source=notifications&email_token=AAFG2WAIUTVKINH3BC4KPATPVQBHFA5CNFSM4HCQ5QP2YY3PNVWWK3TUL52XG43LVMVQNVWWK3TUL52XG43LVMVQNVWWK3TUL52XG4DFVQVR08CB0WM08C0B0B0B0B0B0B0B0
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAFG2WEUDX4DPAB43JVWWV3PVQBHFANCNFSM4HCQ5QPQ
.

@barbushin Я добавил несколько конфигураций, но он не рассчитывает покрытие кода / теста.

Мне кажется, что

Все вопросы решены! :)

Теперь у нас есть только один открытый запрос функции и билет для создания обходного пути для поддержки поиска UTF-8 на глупых серверах Microsoft Exchange.

Следующая задача - очистить и оптимизировать код, чтобы улучшить ремонтопригодность этой библиотеки: https://codeclimate.com/github/barbushin/php-imap/issues

Удачного кодирования!