Autofixture: Что дальше для AutoFixture?

@Kralizek , спасибо, что спросили.

Я могу говорить только за себя, на самом деле (до сих пор), как я написал в https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457:

Меня устраивает, если у меня есть необходимые знания для проверки PR(ов). Обычно я (с удовольствием) просматриваю части кодовой базы, над которыми я ранее работал, создавал или участвовал.

Если я пропустил запрос на вытягивание или проблему, в которой я был явно упомянут, сообщите мне об этом. Однако прошло некоторое время с тех пор, как кто-то добавлял меня в качестве рецензента или явно упоминал меня в проблемах...

Спасибо, @moodmosaic , за указание на #703. Моя позиция все та же, что и тогда: я не участвую в проекте AutoFixture, хотя буду рад помочь советом, если это явным образом будет вызвано.

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

Я все еще могу иногда помочь просмотреть PR в областях, в которых у меня был опыт, но я полагаю, что в наши дни таких областей, вероятно, немного.

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

Я не собираюсь возвращать себе контроль над проектом, но, насколько я могу судить, у меня все еще есть доступ для записи в репозиторий. Если кто-то еще добровольно возглавит проект, я буду рад помочь в этом.

Привет, ребята!

Здесь также отсутствует мой отзыв. Официально нет, но, вероятно, есть ожидания, что на данный момент я был самым активным/ведущим мейнтейнером проекта.

Изначально я был очень увлечен обслуживанием, и у меня было мало идей, что можно было бы улучшить дальше. Даже сегодня я вижу вещи, которые имеет смысл делать, по крайней мере, с точки зрения обслуживания (например, отказаться от поддержки .NET Standard 1.x).

Недавно я вообще отказался от поддержки проекта и сам назвал для этого несколько причин.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ : Цель состоит не в том, чтобы кого-то обвинить, так что не переходите на личности. Скорее, я просто хочу поделиться своим собственным опытом, чтобы мы могли понять, можем ли мы что-то с этим сделать и стоит ли оно того.

Трудно изменить проект.

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

В какой-то момент я начал чувствовать, что мне стало слишком сложно что-либо изменить здесь. И это убило мою страсть к проекту.

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

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

Допускаю, что некоторые мои предложения могли быть не идеальными и, конечно, я не такой опытный, как почтенный Марк. Но мы могли бы быть более свободными в решениях, которые мы принимали, чтобы проект был более живым.

Это немного одиноко

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

Я сейчас не работаю активно с AutoFixture

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

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

Во-первых, я хочу извиниться перед командой @AutoFixture/core за то, что не ответил вам на обсуждение #703. Да, это было занятое время для меня (и до сих пор), но я не был настолько занят, чтобы не мог ответить. Я просто не получал никаких уведомлений ни об одном из моих упоминаний, и я не подумал вернуться к обсуждению. Я буквально только что узнал об этом сейчас, когда снова посетил № 703. Еще раз извините. 😞

Моя позиция относительно будущего AutoFixture такая же, как и в 2016 году . Я считаю, что AutoFixture довольно стабилен и существует уже много лет. Если кто-то хочет пойти в другом направлении, я думаю, им будет лучше начать с чистого листа. Концепция автоматической генерации тестовых данных очень хороша, и AutoFixture, безусловно, не единственный способ, которым это можно сделать на платформе .NET.

Это не означает, что AutoFixture не содержит ошибок. Я хочу сказать, что объем и объем технического обслуживания достаточно малы, чтобы ответственность за них могла по-прежнему нести команда @AutoFixture/core.

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

Я говорю, что мы пытаемся двигаться вперед с текущей моделью за вычетом назначенного лидера и посмотрим, как это пойдет.

AutoFixture — такой хороший проект, что будет очень грустно видеть, как он медленно исчезает.

Поскольку @zvirja является самым активным/ведущим сопровождающим проекта. Я считаю, что для него имеет смысл руководить тем, как будет развиваться этот проект. Поддержка проекта с открытым исходным кодом требует много усилий и времени. Лично я не против пожертвовать, чтобы этот проект продолжался. И спасибо @zvirja

Кто-то должен указать на слона в комнате, так что это может быть и я.

Эта ветка очень похожа на похороны (или на сожаление)

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

1. Текущие сопровождающие не имеют времени/не заинтересованы в проекте
2. Проект сложно поддерживать
3. Код-ревью слишком ограничен

Теперь мы можем составить список действий, которые мы можем предпринять?

Если кого-то волнует, вот мой взгляд на это:

1. Принимайте новых участников в сообщество. @Kralizek существует уже некоторое время, он может быть хорошим кандидатом. Может быть, есть другая команда вместе с @AutoFixture/core?
2. Создайте список проблем, расставьте приоритеты, обратитесь за помощью к сообществу
3. Ослабьте код-ревью. Нельзя стать владельцем проекта, если предыдущий владелец постоянно бьет его по рукам.
   Разрешить эксперименты, возможно, создать дополнительный пакет AutoFixture.Experimental для вещей, которые еще не подтверждены для получения основной версии библиотеки (например, Boost для стандартной библиотеки C++).

Я согласен с @zvirja , проект очень пугающий. Я открыл для себя AutoFixture около двух лет назад и только недавно набрался смелости представить PR.
Я верю, что есть и другие, которые чувствуют то же самое. Люди, которые используют этот инструмент и хотят, чтобы он процветал.

Спасибо @aivascu за указание на слона в комнате.

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

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

Я могу с радостью вмешаться, когда дело доходит до пользовательского опыта...

Как насчет программы спонсорства/поддержки, чтобы подогреть энтузиазм для поддержки проекта?
В конце концов, это популярное репо.

Мои два цента использования AutoFixture за последние три года:

Я думаю, что торговая марка AutoFixture великолепна. Это крутое имя.

Он популярен в Stack Overflow. У [autofixture] есть 506 вопросов, тогда как у [xunit.net] есть 801. То, что он почти так же популярен, как квазиофициальная среда тестирования .NET Core, довольно примечательно, и отчасти благодаря неустанной преданности Марка. преподавать (и быть великим учителем). А блог Марка — это кладезь бесплатных знаний по тестированию.

Я думаю, что API AutoFixture довольно сложно изучить.

Части AutoFixture, которые мне нравятся:

• Возможность использовать шаблон проектирования Auto-Mocking Container (вероятно, самая мощная концепция тестирования, с которой я познакомился как инженер).
• Fixture.Freeze потрясающе
• Расширение AutoMoq, позволяющее быстро создавать фикстуры для вещей, требующих макета.
• Возможность автоматически генерировать граф объектных объектов и тестировать общий шаблон репозитория, а также гарантировать сквозное покрытие кода интеграционного тестирования для моих репозиториев Entity Framework.

Части AutoFixture, которые я никогда не использую напрямую:

• Fixture.Inject

Части AutoFixture, которые я хочу улучшить/расширить

• Смотрите мою проблему, созданную вчера: # 1179
• Возможность заменить поведение Guids по умолчанию для строк на что-то более приятное, например Waffle Text Generator. Я понимаю, что вы можете сделать это сегодня, но если бы над #1179 поработали, то мы могли бы подключить средства выбора произвольных элементов с помощью пользовательского поставщика данных.
• AutoFixture медленный и не использует современные приемы для ускорения компиляции выражений, как это делает проект DryIoC Максима Волкау с FastExpressionCompiler Максима https://github.com/dadhi/FastExpressionCompiler .

Части AutoFixture, которые мне не нравятся (в основном второстепенные):

• Fixture.Customizeвсегда некорректно работает с Visual Studio intellisense.
• Написание настроек и почему метод Customize не позволяет внедрить настройку. Подобные вещи причудливы и раздражают, и они создают огромную кривую обучения.
• Индивидуальные настройки, сборщики образцов и прочее повсюду. Это неорганизованно.
• Странная лексика для некоторых вещей
• Ко всему шаблону проектирования Do..Without довольно сложно привыкнуть. Это работает, но многословно и не помогает вам с рекурсивными сущностями. Для этого вам нужны специальные Behaviors, чтобы указать AutoFixture создать хэш-таблицу уже созданных объектов.
• Нет упрощенного синтаксиса для общих задач
• Монолитная конструкция, требующая глубокого понимания внутренностей только для решения проблем. Вы не можете просто использовать кусочки. Вам придется в значительной степени просмотреть курс Марка PluralSight, чтобы пройти начальную кривую обучения, или поработать с разработчиком, который является экспертом в AutoFixture, чтобы понять, почему AutoFixture такой классный.
• Позиция Марка о том, что AutoFixture должна генерировать только «анонимные значения». Это создает много стороннего написания кода, чтобы что-то сделать. Примеры включают следующие сообщения StackOverflow:
  
  
  
  • Автофиксация, создание списка словаряс переменным ключом
  
  
  • Как назначить свойство только для поддиапазона элементов в списке?
  
  
  • Как создать список классов, для которых в AutoFixture всегда задано предопределенное значение?
  
  

Части, в которых я вижу возможности для инноваций:

• По мере того, как C# становится все более и более функциональным (сопоставление шаблонов, типы записей и т. д.), AutoFixture в идеале должен работать все больше и больше, как FsCheck и Hedgehog в F#.
• Было бы неплохо, если бы AutoFixture смогла воплотить в жизнь некоторые концепции конколического тестирования из FsCheck, такие как функция Arb.
• Используйте инновации, подобные тем, что обсуждались в RLCheck, чтобы позволить инженерам создавать сверхнадежные и разнообразные тестовые входные данные (Guid as string — это хак!) https://www.carolemieux.com/rlcheck_preprint.pdf

Я думаю, что некоторые из проблем, которые я описываю здесь, связаны с тем, почему Microsoft не будет использовать AutoFixture ни в одном из своих тестов для .NET Core.

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

Похоже, что экспериментальный форк может быть выходом.

Почему вы хотите это сделать? Вам придется поддерживать эту вилку. Если вы готовы сделать это, почему бы вместо этого не стать сопровождающим этого репозитория?

Вместо экспериментального форка я бы подумал о создании нового репозитория (или продолжении работы над этим), чтобы внедрить улучшения QoL, которые обсуждались выше.

AutoFixture имеет мощный API, который может многого добиться, но может отпугнуть многих людей. Большинство вещей можно представить как простой синтаксический сахар.

внедрить улучшения качества жизни

Ренато ( @Kralizek ), что означает QoL? Качество жизни?

Ага.

Если вы готовы сделать это, почему бы вместо этого не стать сопровождающим этого репозитория?

@ploeh , как можно стать сопровождающим репозитория? Есть ли какие-то требования?
Честно говоря, если посмотреть на текущий список сопровождающих, то можно заметить, что есть кое-что важное.
Я хотел бы внести свой вклад в AutoFixture, может быть, даже в качестве сопровождающего (когда-нибудь), и я уверен, что есть и другие, но я полагаю, что никто не будет принят для поддержки такого популярного репозитория.

Почему вы хотите это сделать? Вам придется поддерживать эту вилку.

Я согласен с этой цитатой. Когда я впервые предложил экспериментальный пакет в этой ветке, я думал о способе смягчения проблем, которые были у @zvirja , при сохранении репозитория. Пакет должен был содержать функции, построенные поверх ядра AutoFixture, а не измененную вилку. Что-то вроде того, что описал @Kralizek .
Конечно, в идеале такой пакет не нужен. Я думаю, что мы должны решить проблему людей, а не проблему технологий.

Я думаю, что мы должны решить проблему людей, а не проблему технологий.

Я не знаю, что это значит. Расскажите подробнее.

Я думаю, что мы должны решить проблему людей, а не проблему технологий.

Я не знаю, что это значит. Расскажите подробнее.

Я думаю, он имеет в виду, что AutoFixture нуждается в преданных мейнтейнерах, которые могут свободно вводить новшества, не опасаясь уничтожить прекрасное произведение искусства, что касается того, что @zvirja сказал в своем комментарии .

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

Несколько интересных идей были отклонены из-за того, что они противоречили «Старым обычаям». Это убьет чью-либо мотивацию. С этой точки зрения форк освободил бы много этого багажа.

Хорошо, я простой парень, я просто хочу объединить такие вещи, как https://github.com/AutoFixture/AutoFixture/pull/928 . Как я упоминал выше, в AutoFixture нет хороших способов поддержки создания уникальных значений. Мультипликативный линейный конгруэнтный генератор кажется хорошей основой для такой функции. Мы недавно написали свой собственный, и он был не так умен, как кто-то, кто знал об этом трюке, и я нашел PR только позже.

Я такой: «Да, давайте делать больше таких крутых вещей».

как стать сопровождающим репозитория?

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

Есть ли какие-то требования? Честно говоря, если посмотреть на текущий список сопровождающих, то можно заметить, что есть кое-что важное.

Не беспокойтесь о прошлом. Прямо сейчас, если я правильно понял ситуацию, AutoFixture мертв в воде. Если кто-то не возьмет на себя задачу ее выполнения, ничего не изменится.

Таким образом, вы можете совершить все ошибки в мире и вряд ли сделаете хуже.

@ploeh , если вы так выразились, то я был бы рад стать сопровождающим, и я надеюсь, что другие тоже сделают это.

@aivascu Спасибо, это здорово.

Я дам текущим сопровождающим и тусовщикам @zvirja , @moodmosaic , @adamchester , @ecampidoglio около 24 часов, чтобы прокомментировать это, и если я не увижу никаких протестов, я дам вам права сопровождающего.

@ploeh Никаких возражений с моей стороны.
@aivascu Добро пожаловать на борт. Надеюсь, этот проект доставит вам удовольствие, которое вы ищете 😊

@aivascu Я не сопровождаю, но мне нравится эта библиотека. Просто позвоните мне, если вам нужно, чтобы кто-то передал ваши мысли.

@ploeh , @aivascu , я в порядке :+1: :rocket:

Я рад обсудить части кодовой базы, над которыми я работал, создавал или участвовал. Если я пропустил запрос на вытягивание (или проблему), в которой меня упомянули, сообщите мне об этом.

@aivascu Мои наилучшие пожелания тебе. Мой единственный совет: на каждые 20 000 строк кода в кодовой базе может уйти около 6 месяцев, особенно если в одном месте нет четких «записей архитектурных решений». По этой причине в проектах, которые я поддерживаю, я начал писать так, чтобы люди понимали «стиль» кода. Марк написал их, но в основном в своем блоге и/или StackOverflow. @moodmosaic сделал то же самое. Я бы сказал, что в будущем создайте папку adr в корне репозитория, в которой будут документированы любые обоснования дизайна. Для этого вы можете использовать файлы .md. Для сложных таблиц используйте HTML-таблицы, а не таблицы уценки.

Спасибо всем за теплый прием.
Думаю, для начала я воспользуюсь советом @jzabroski и начну заполнять пробелы в документации , чтобы облегчить адаптацию новых сопровождающих и участников.
Параллельно, возможно, я смогу начать прожигать существующий бэклог.
Будем надеяться, что больше членов сообщества примут участие в развитии этого замечательного инструмента.

Поздравляю @aivascu.

Я чувствую, что ты теперь ведущий разработчик. Я говорю это, потому что чувствую, что все вернется в «мертвое» состояние, которым они являются сейчас, как только вы остановитесь - поэтому я смотрю на вас сейчас :)

Я надеюсь, что команда Autofixture «выслеживает» новых членов команды, чтобы снизить риск проблемы одинокого путешествия, упомянутой ранее. Я рад внести свой вклад только в том случае, если кто-то может взглянуть на это https://github.com/AutoFixture/AutoFixture/pull/1164.

@aivascu Я отправил вам приглашение присоединиться к основной команде AutoFixture, но приглашение все еще находится на рассмотрении.

@ploeh Я только что принял приглашение. Спасибо!

@aivascu 👍 Добро пожаловать в команду.

Если я могу чем-то еще помочь вам, я буду рад. Однако я не принимал участия в проекте в течение многих лет, поэтому я больше не знаю, как работают какие-либо практические вещи. Я надеюсь, что @zvirja сможет рассказать вам об этих деталях.

Спасибо!

Добро пожаловать @aivascu

@aivascu Я был бы рад включить вас в проект. Если вы не возражаете, я был бы очень рад поговорить с вами голосом, чтобы я мог все показать и ответить на вопросы. Если вы готовы к этому, пожалуйста, напишите мне письмо (вы можете найти адрес в коммитах), чтобы мы могли согласовать детали.

И снова добро пожаловать.

@zvirja , это было бы очень мило. Я напишу вам письмо.

Добро пожаловать @aivascu :+1:

Добро пожаловать на борт, @aivascu! 🙂

@aivascu Учитывая, что вы выступили в качестве нового сопровождающего, полного страсти и энергии, чтобы работать над этим, мы должны просто закрыть и открепить эту проблему? Типа сказать, что на данный момент наше будущее определено? 😄

@zvirja Я как бы надеялся, что кто-то еще может попросить заполнить ряды сопровождающих. 😄

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