Autofixture: O que vem a seguir para o AutoFixture?

@Kralizek , obrigado por perguntar.

Só posso falar por mim, na verdade é (ainda) como escrevi em https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457:

Tudo bem por mim, se eu tiver o conhecimento necessário para revisar o(s) PR(s). Normalmente, eu (felizmente) reviso partes da base de código em que trabalhei, criei ou contribuí anteriormente.

Se eu perdi um pull request ou um problema em que fui explicitamente mencionado, por favor me avise. Já faz um tempo desde que alguém me adicionou como revisor, ou me mencionou explicitamente em questões...

Obrigado, @moodmosaic , por apontar para o número 703. Minha posição ainda é a mesma da época: estou fora do projeto AutoFixture, embora fique feliz em ajudar com conselhos, se explicitamente invocado.

Acho que faz sentido abrir esta questão se nada parece estar acontecendo. Pode ser que os mantenedores atuais também tenham se mudado. Vamos ver se obtemos uma resposta de algum deles. Se não, por favor, me ligue novamente, deveríamos dizer, uma semana ou mais?

Ainda posso ajudar a revisar as relações públicas ocasionais em áreas com as quais tive experiência, mas acho que essas áreas provavelmente são poucas e distantes entre si nos dias de hoje.

Se as coisas não estão se movendo, vamos ver se podemos descobrir o porquê, e então ver se podemos ajudar a encontrar mais pessoas para ajudar, se necessário.

Não pretendo retomar o controle do projeto, mas até onde sei, ainda tenho acesso de gravação ao repositório. Se alguém se voluntariar para liderar o projeto, ficarei feliz em ajudar a fazer isso acontecer.

Oi pessoal!

Também está faltando meu feedback aqui. Não oficialmente, mas provavelmente há expectativas de que eu fosse o mantenedor mais ativo/líder do projeto por enquanto.

Inicialmente fui muito apaixonado por manutenção e tinha poucas ideias do que poderia ser melhorado ainda mais. Ainda hoje vejo coisas que fazem sentido fazer, pelo menos do ponto de vista da manutenção (por exemplo, descartar o suporte ao .NET Standard 1.x).

Recentemente, deixei de apoiar o projeto e identifiquei algumas razões para isso.

IMPORTANTE : O objetivo não é culpar ninguém, então não entenda pessoalmente. Em vez disso, quero apenas compartilhar minha própria experiência para que possamos ver se há algo que possamos fazer sobre isso e se vale a pena.

É difícil mudar o projeto.

É muito difícil mudar este projeto, pois tenho a forte sensação de que todos tentam preservar o legado que Mark deixou. Não há liberdade para tentar qualquer outra coisa, exceto o que Mark faria. Mark foi citado em quase todos os PR onde não participou pessoalmente :)

Em algum momento comecei a sentir que se tornou muito difícil modificar qualquer coisa aqui. E matou a paixão que eu tinha pelo projeto.

Embora Mark tenha saído, ainda sinto pessoalmente que a propriedade do projeto ainda pertence a ele. Eu sinto muita pressão interna/externa ao tomar as decisões, pois há uma chance de quebrar violenta e barbaramente algo que foi tão bem trabalhado por Mark. Parte dessa percepção foi criada exclusivamente por mim, mas há partes em que outros mantenedores contribuíram para causar tal impressão.

Provavelmente é apenas a diferença com minhas expectativas e realidade. Achei que poderia expressar e testar minhas ideias com este projeto, que será ágil, fresco e cheio de novidades. Mas, na realidade, parecia um projeto legado onde você não tem permissão para mudar muito, pois as coisas estão funcionando bem de qualquer maneira.

Admito que algumas das minhas propostas podem não ter sido as ideais e, claro, não sou tão experiente como o honorável Mark. Mas poderíamos ter sido mais livres nas decisões que tomamos, então o projeto está mais vivo.

É um pouco solitário

Quando entrei no projeto, entre outros, esperava participar de discussões ágeis, fazer parte da equipe, socializar com outras pessoas. Infelizmente, devido à sorte do tempo e/ou outros fatores, outros mantenedores não participaram muito das discussões e eventualmente comecei a sentir que estou sozinho aqui. Eu sinto que outros mantenedores não têm muito tempo/paixão por este projeto no momento, então finalmente comecei a compartilhar o mesmo.

Não estou trabalhando ativamente com o AutoFixture no momento

No momento, não estou escrevendo muito código de back-end, portanto, não use muito o AutoFixture. Eu ainda sou uma grande diversão do projeto e acredito que esta biblioteca é obrigatória. Mas como não estou escrevendo muitos testes, pessoalmente não exijo nenhuma mudança.

Indo mais longe, não me importo de participar da vida do projeto e compartilhar meu conhecimento se for o caso. Se houver necessidade, eu poderia ajudar com o código/manutenção também. Mas neste momento, infelizmente, não tenho paixão e energia suficientes para ser um mantenedor de liderança. Se tivermos algum candidato para isso em quem confiamos e que seja cheio de paixão, definitivamente devemos convidá-lo e fazer um dos mantenedores.

Primeiro, quero me desculpar com a equipe @AutoFixture/core por não ter respondido a você na discussão #703. Sim, foi uma época ocupada para mim (e ainda é), mas não estava tão ocupada que não pudesse responder. Eu simplesmente não recebi nenhuma notificação para nenhuma das minhas menções e não pensei em verificar novamente a discussão. Literalmente acabei de descobrir sobre isso agora que revisitei o número 703. Mais uma vez, me desculpe. 😞

Minha posição sobre o futuro do AutoFixture é a mesma que expressei em 2016 . Eu acredito que o AutoFixture é bastante estável e tem sido há anos. Se alguém quiser tomar uma direção diferente, acho que seria melhor começar do zero. O conceito de geração automática de dados de teste é muito bom e o AutoFixture certamente não é a _única_ maneira que poderia ser feito na plataforma .NET.

Isso não quer dizer que o AutoFixture seja livre de bugs. O que estou dizendo é que o volume e o escopo da manutenção são pequenos o suficiente para continuar sendo responsabilidade da equipe @AutoFixture/core.

Precisamos de um desenvolvedor líder? A história do código aberto parece sugerir que um projeto sem um líder individual acabará sendo abandonado. Mas e quanto a um grupo de leads?

Digo que tentamos seguir em frente com o modelo atual menos uma liderança apontada e ver como corre.

O AutoFixture é um projeto tão bom que será muito triste vê-lo desaparecer lentamente.

Já que @zvirja é o mantenedor mais ativo/líder do projeto. Eu acredito que faz sentido para ele liderar como este projeto irá evoluir. Manter um projeto de código aberto exige muito esforço e tempo. Pessoalmente, não me importo de doar para fazer este projeto ir. E obrigado @zvirja

Alguém deveria apontar o elefante na sala, então poderia ser eu.

Este tópico se parece muito com um funeral (ou uma perspectiva de arrependimento)

Acredito que nós (a comunidade) deveríamos nos concentrar mais em encontrar uma saída para a situação em que nos encontramos do que em pedir desculpas.
Até agora, este tópico tem sido muito bom em apontar os problemas (sinta-se à vontade para completar):

1. Os mantenedores atuais não têm tempo/não estão interessados ​​no projeto
2. O projeto é difícil de manter
3. A revisão de código é muito restritiva

Agora podemos apresentar uma lista de ações que podemos tomar?

Se alguém se importa aqui está a minha opinião sobre isso:

1. Aceite novos membros na comunidade. @Kralizek já existe há algum tempo, ele pode ser um bom candidato. Talvez tenha outra equipe ao lado de @AutoFixture/core?
2. Crie uma lista de pendências, priorize, peça ajuda à comunidade
3. Afrouxe a revisão de código. Não se pode assumir a propriedade de um projeto se ele está constantemente sendo esbofeteado pelo proprietário anterior.
   Permitir experimentos, talvez criar um pacote adicional AutoFixture.Experimental , para o material, que ainda não está confirmado para chegar à versão principal da biblioteca (como Boost é para a biblioteca C++ padrão).

Concordo com @zvirja , o projeto é muito intimidador. Descobri o AutoFixture há cerca de dois anos e só recentemente tive coragem de enviar um PR.
Acredito que existam outros que sintam o mesmo. Pessoas que estão usando a ferramenta e gostariam de vê-la prosperar.

Obrigado @aivascu por apontar para o elefante na sala.

Eu concordo com sua análise, mas eu também teria uma quarta opção (embora eu a odiasse): um novo fork para dar aos seus mantenedores liberdade para se movimentar e mexer.

Além disso, obrigado por colocar meu nome na lista, mas infelizmente não sou tão experiente com os componentes internos da biblioteca e realmente não consigo me mexer nela.

Posso intervir com prazer quando se trata da experiência do usuário...

Que tal um programa de patrocínio/apoio para despertar algum entusiasmo pela manutenção do projeto?
Afinal, é um repositório popular.

Meus dois centavos usando o AutoFixture nos últimos três anos:

Eu acho que o nome da marca AutoFixture é ótimo. É um nome legal.

É popular no Stack Overflow. [autofixture] tem 506 perguntas, enquanto [xunit.net] tem 801. Para ser quase tão popular quanto a estrutura de teste quase oficial do .NET Core é bastante notável, e em parte devido à dedicação implacável de Mark para ensinar (e ser um grande professor). E o blog de Mark é como uma fonte de conhecimento de teste gratuito.

Eu acho que a API do AutoFixture é bastante difícil de aprender.

Partes do AutoFixture que eu amo:

• Capacidade de usar o padrão de projeto Auto-Mocking Container (provavelmente o conceito de teste mais poderoso ao qual fui apresentado como engenheiro).
• Fixture.Freeze é incrível
• Extensão AutoMoq para permitir a criação rápida de acessórios para coisas que exigem uma simulação
• Capacidade de gerar automaticamente um gráfico de objeto de entidade e testar meu padrão de repositório genérico e garantir cobertura de código de teste de integração de ponta a ponta para meus repositórios do Entity Framework.

Partes do AutoFixture que nunca uso diretamente:

• Dispositivo elétrico.Injetar

Partes do AutoFixture que eu quero melhorar/estender

• Veja meu problema criado ontem: #1179
• Capacidade de trocar o comportamento padrão de Guids por strings com algo melhor, como o Waffle Text Generator. Eu sei que você pode fazer isso hoje, mas se #1179 fosse trabalhado, então poderíamos conectar Arbitrary Element Pickers com um provedor de dados personalizado.
• O AutoFixture é lento e não usa truques modernos para acelerar a compilação de expressões, como o projeto DryIoC de Maksim Volkau faz com o FastExpressionCompiler de Maksim https://github.com/dadhi/FastExpressionCompiler

Partes do AutoFixture que eu não amo (principalmente menores):

• Luminária.Personalizarsempre funciona incorretamente com o Visual Studio intellisense.
• Escrevendo personalizações e por que o método Customize não permite que você injete uma personalização. Esse tipo de coisa é barroco e irritante e cria uma enorme curva de aprendizado.
• Personalizações e construtores de espécimes e coisas estão por toda parte. Está desorganizado.
• Vocabulário estranho para algumas coisas
• Todo o padrão de design Do..Without é bastante difícil de se acostumar. Funciona, mas é detalhado e não ajuda com entidades recursivas. Para isso, você precisa de comportamentos especiais para dizer ao AutoFixture para criar uma tabela de hash de objetos já criados.
• Sem sintaxe simplificada para tarefas comuns
• Design monolítico que requer uma compreensão profunda das partes internas apenas para resolver problemas. Você não pode simplesmente usar pedaços e peças. Você precisa assistir ao curso PluralSight de Mark apenas para superar a curva de aprendizado inicial ou trabalhar com um desenvolvedor especialista em AutoFixture, para entender por que o AutoFixture é tão incrível.
• A posição de Mark de que o AutoFixture deve gerar apenas "valores anônimos". Ele cria muita escrita de código de terceiros para fazer as coisas. Os exemplos incluem as seguintes postagens do StackOverflow:
  
  
  
  • Autofixture, crie uma lista de dicionáriocom chave alternada
  
  
  • Como atribuo uma propriedade em apenas um subintervalo de itens em uma lista?
  
  
  • Como crio uma lista de classes que sempre têm um valor predefinido definido em AutoFixture?
  
  

Peças que vejo possibilidade de inovação:

• À medida que o C# se torna cada vez mais funcional (correspondência de padrões, tipos de registro, etc), o AutoFixture funcionaria cada vez mais como FsCheck e Hedgehog em F#.
• Seria bom se o AutoFixture fosse capaz de reificar alguns conceitos de testes concólicos do FsCheck, como o recurso Arb.
• Use inovações como as discutidas no RLCheck para permitir que os engenheiros criem entradas de teste super robustas e diversas (Guid as string é um hack!) https://www.carolemieux.com/rlcheck_preprint.pdf

Acho que alguns dos problemas que descrevo aqui são por que a Microsoft não usará o AutoFixture em nenhum de seus testes para .NET Core.

Parece que um garfo experimental pode ser o caminho a percorrer. O AutoFixture está entre os poucos projetos de código aberto que conheço que estão em uso diário generalizado pelos desenvolvedores, podem definitivamente se beneficiar de recursos adicionais e facilidade de uso aprimorada e tem uma base de código de alta qualidade por trás dele. Não consigo imaginar que o interesse seria baixo se as preocupações sobre contribuir e mudar de direção fossem mitigadas, que é o que um fork ativo faria.

Parece que um garfo experimental pode ser o caminho a percorrer.

Por que você gostaria de fazer isso? Você teria que manter esse garfo. Se você estiver disposto a fazer isso, por que não se tornar um mantenedor deste repositório?

Em vez de um fork experimental, eu consideraria criar um novo repositório (ou continuar desenvolvendo este) para introduzir as melhorias de QoL discutidas acima.

O AutoFixture possui uma API poderosa que pode alcançar muito, mas pode assustar muitas pessoas. A maioria das coisas pode ser introduzida como simples açúcar sintático.

para introduzir as melhorias de qualidade de vida

Renato ( @Kralizek ), o que significa QV? Qualidade de vida?

Sim.

Se você estiver disposto a fazer isso, por que não se tornar um mantenedor deste repositório?

@ploeh como alguém se torna um mantenedor do repositório? Existem requisitos?
Para ser honesto, olhando para a lista atual de mantenedores, há alguns grandes sapatos a serem preenchidos.
Eu gostaria de contribuir com o AutoFixture, talvez até como mantenedor (um dia) e tenho certeza que existem outros, mas imagino que não seja qualquer um que seria aceito para manter um repositório tão popular.

Por que você gostaria de fazer isso? Você teria que manter esse garfo.

Eu concordo com essa citação. Quando propus inicialmente um pacote experimental, neste tópico, estava pensando em uma maneira de mitigar os problemas que o @zvirja tinha, mantendo o repositório. O pacote conteria recursos construídos em cima do núcleo AutoFixture, não um fork alterado. Algo como o que @Kralizek descreveu.
Claro que, idealmente, um pacote como este não seria necessário. O que eu acho que devemos resolver é o problema das pessoas e não um problema de tecnologia.

O que eu acho que devemos resolver é o problema das pessoas e não um problema de tecnologia.

Eu não sei o que isso significa. Conte-nos mais.

O que eu acho que devemos resolver é o problema das pessoas e não um problema de tecnologia.

Eu não sei o que isso significa. Conte-nos mais.

Acho que o que ele quer dizer é que a AutoFixture precisa de mantenedores comprometidos que se sintam à vontade para inovar sem medo de destruir uma bela obra de arte, como disse @zvirja em seu comentário .

É difícil se sentir comprometido com algo em que você sente que suas mãos estão atadas pela sombra lançada por decisões e lideranças anteriores.

Poucas ideias interessantes foram rejeitadas porque estavam em conflito com os "Velhos Maneiras". Isso mataria a motivação de qualquer um. Desse ponto de vista, um garfo liberaria muito dessa bagagem.

OK, sou um cara simples, só quero coisas como https://github.com/AutoFixture/AutoFixture/pull/928 mescladas. Como mencionei acima, o AutoFixture não possui boas maneiras de oferecer suporte à geração de valores exclusivos. O gerador congruente linear multiplicativo parece ser uma boa base para tal recurso. Recentemente escrevemos nosso próprio e não era tão inteligente quanto alguém que conhecia esse truque, e só encontrei o PR mais tarde.

Eu estou tipo, "Sim, vamos fazer mais dessas coisas legais."

como se torna um mantenedor do repositório?

Você basicamente afirma que está disposto a assumir essa responsabilidade. Até onde posso dizer, ainda tenho direitos de administrador no repositório e, embora nenhum dos mantenedores atuais tenha declarado explicitamente isso, tenho a impressão de que nenhum deles levará isso adiante.

Existem requisitos? Para ser honesto, olhando para a lista atual de mantenedores, há alguns grandes sapatos a serem preenchidos.

Não se preocupe com o passado. Agora, se eu ler a situação corretamente, o AutoFixture está morto na água. A menos que alguém assuma a tarefa de levá-la adiante, nada vai mudar.

Assim, você pode cometer todos os erros do mundo e dificilmente piorará as coisas.

@ploeh , se você colocar assim, ficaria feliz em avançar como mantenedor e espero que outros também o façam.

@aivascu Obrigado, isso é ótimo.

Darei aos mantenedores atuais e hangarounds @zvirja , @moodmosaic , @adamchester , @ecampidoglio cerca de 24 horas para comentar sobre isso, e se eu não vir nenhum protesto, darei a você os direitos de mantenedor.

@ploeh Sem objeções do meu lado.
@aivascu Bem-vindo a bordo. Espero que este projeto traga a diversão que você procura 😊

@aivascu Não sou mantenedor, mas adoro essa biblioteca. Apenas me ligue se precisar de alguém para refletir seus pensamentos.

@ploeh , @aivascu , tudo bem por mim :+1: :rocket:

Fico feliz em discutir sobre partes da base de código em que trabalhei, criei ou contribuí. Se eu perdi um pull request (ou um problema) em que fui mencionado, por favor me avise.

@aivascu Meus melhores desejos para você. Meu único conselho é que pode levar cerca de 6 meses para cada 20.000 linhas de código em uma base de código, especialmente se não houver alguns "registros de decisão de arquitetura" claros em um só lugar. Por esta razão, nos projetos que mantenho, comecei a escrevê-los para que as pessoas entendam o "estilo" do código. Mark escreveu isso, mas principalmente em seu blog e/ou StackOverflow. @moodmosaic fez o mesmo. Eu diria que, daqui para frente, crie uma pasta adr na raiz do repositório que documente qualquer lógica de design. Você pode usar arquivos .md para isso. Para tabelas complexas, use tabelas html em vez de tabelas de remarcação.

Obrigado a todos pela calorosa recepção.
Acho que, para começar, vou seguir o conselho de @jzabroski e começar a preencher as lacunas na documentação para facilitar a integração de novos mantenedores e contribuidores.
Em paralelo, talvez eu possa começar a queimar o backlog existente.
Espero que haja mais membros da comunidade avançando para levar adiante essa ferramenta incrível.

Parabéns @aivascu.

Eu sinto que você é o desenvolvedor líder agora. Estou dizendo isso porque sinto que as coisas voltarão ao estado 'morto' que estão agora, assim que você parar - então estou olhando para você agora :)

Espero que a equipe Autofixture 'cace' novos membros da equipe, para mitigar o risco do problema da jornada solitária mencionado anteriormente. Fico feliz em contribuir apenas, se alguém puder dar uma olhada neste https://github.com/AutoFixture/AutoFixture/pull/1164.

@aivascu Enviei um convite para você se juntar à equipe principal do AutoFixture, mas o convite ainda está pendente.

@ploeh Acabei de aceitar o convite. Obrigada!

@aivascu 👍 Bem vindo ao time.

Se houver mais coisas que eu possa fazer para ajudá-lo, ficarei feliz em fazê-lo. No entanto, estou inativo no projeto há anos, então não sei mais como funciona nenhuma das coisas práticas. Espero que @zvirja possa te informar sobre esses detalhes.

Obrigada!

Bem vindo @aivascu

@aivascu , ficaria feliz em acompanhá-lo ao projeto. Se você não se importa, eu ficaria muito feliz em ter uma conversa de voz com você, para que eu possa mostrar tudo e responder às perguntas. Se você estiver disposto a isso, por favor me escreva um e-mail (você pode encontrar o endereço em commits) para que possamos concordar com os detalhes.

E bem-vindo novamente.

@zvirja isso seria muito bom. Vou te deixar um e-mail.

Bem vindo @aivascu :+1:

Bem-vindo a bordo, @aivascu! 🙂

@aivascu Dado que você se tornou um novo mantenedor cheio de paixão e energia para trabalhar nisso, devemos apenas fechar e desafixar esse problema? Tipo dizer que por enquanto nosso futuro está determinado? 😄

@zvirja Eu meio que esperava que alguém pudesse solicitar para preencher as fileiras de mantenedores. 😄

Se alguém sentir que pode gostar de ser um mantenedor deste repositório, abra um problema ou envie-nos uma mensagem.
Vou encerrar o assunto agora.