Autofixture: ¿Qué sigue para AutoFixture?

@Kralizek , gracias por preguntar.

Solo puedo hablar por mí mismo, en realidad es (todavía) como escribí en https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457:

Bien por mí, si tengo los conocimientos necesarios para revisar los PR. Por lo general, (felizmente) reviso partes del código base en las que he trabajado, creado o contribuido previamente.

Si me perdí una solicitud de extracción o un problema en el que se me mencionó explícitamente, házmelo saber. Sin embargo, ha pasado un tiempo desde que alguien me agregó como revisor o me mencionó explícitamente en un problema (s)...

Gracias, @moodmosaic , por señalar el #703. Mi posición sigue siendo la misma que en ese entonces: estoy fuera del proyecto AutoFixture, aunque estoy feliz de ayudar con consejos si se me invoca explícitamente.

Creo que tiene sentido abrir este problema si nada parece estar sucediendo. Puede ser que los mantenedores actuales también hayan seguido adelante. A ver si obtenemos respuesta de alguno de ellos. Si no es así, por favor, hágame un ping de nuevo dentro de, digamos, una semana más o menos.

Todavía puedo ayudar a revisar las relaciones públicas ocasionales en áreas con las que he tenido experiencia, pero supongo que esas áreas son probablemente pocas y distantes entre sí en estos días.

Si las cosas no se mueven, veamos si podemos averiguar por qué, y luego veamos si podemos ayudar a encontrar más personas para ayudar si es necesario.

No tengo la intención de recuperar el control del proyecto, pero por lo que sé, todavía tengo acceso de escritura al repositorio. Si alguien más se ofrece como voluntario para liderar el proyecto, estaré feliz de ayudar a que eso suceda.

¡Hola tios!

También faltan mis comentarios aquí. No oficialmente, pero probablemente haya expectativas de que yo sea el mantenedor más activo/principal del proyecto por ahora.

Inicialmente, me apasionaba mucho el mantenimiento y tenía pocas ideas sobre lo que podría mejorarse aún más. Incluso hoy veo cosas que tiene sentido hacer, al menos desde la perspectiva del mantenimiento (p. ej., eliminar el soporte de .NET Standard 1.x).

Recientemente me retiré de apoyar el proyecto y identifiqué algunas razones para esto.

DESCARGO DE RESPONSABILIDAD : El propósito no es culpar a nadie, así que no lo entiendas personalmente. Más bien, solo quiero compartir mi propia experiencia para que podamos ver si hay algo que podamos hacer al respecto y si vale la pena.

Es difícil cambiar el proyecto.

Es muy difícil cambiar este proyecto, ya que tengo la fuerte sensación de que todo el mundo trata de preservar el legado que dejó Mark. No hay libertad para probar nada más, excepto lo que haría Mark. Mark fue citado en casi todas las relaciones públicas en las que no participó en persona :)

En algún momento comencé a sentir que se me hacía muy difícil modificar algo aquí. Y mató la pasión que tenía por el proyecto.

Aunque Mark se fue, personalmente sigo sintiendo que la propiedad del proyecto todavía le pertenece a él. Siento mucha presión interna/externa cuando tomo las decisiones, ya que existe la posibilidad de romper de manera violenta y bárbara algo que fue tan bien diseñado por Mark. Parte de esta percepción fue creada únicamente por mí, pero hay partes en las que otros mantenedores contribuyeron a causar tal impresión.

Probablemente es solo la diferencia con mis expectativas y la realidad. Pensé que podría expresar y probar mis ideas con este proyecto, que será ágil, fresco y lleno de novedades. Pero en realidad se sintió como un proyecto heredado en el que no se le permite cambiar mucho, ya que las cosas funcionan bien de todos modos.

Admito que algunas de mis propuestas podrían no haber sido ideales y, por supuesto, no tengo tanta experiencia como el honorable Mark. Pero podríamos haber sido más libres en las decisiones que tomamos, para que el proyecto esté más vivo.

es un poco solitario

Cuando me uní al proyecto, entre otros, esperaba participar en discusiones ágiles, ser parte del equipo, socializar con otros. Desafortunadamente, debido a la suerte del tiempo y/u otros factores, otros mantenedores no participaron demasiado en las discusiones y eventualmente comencé a sentir que estaba solo aquí. Siento que otros mantenedores no tienen demasiado tiempo/pasión por este proyecto en este momento, así que finalmente comencé a compartir lo mismo.

No estoy trabajando activamente con AutoFixture en este momento

Por el momento no estoy escribiendo mucho código back-end, así que no use demasiado AutoFixture. Todavía me divierte mucho el proyecto y creo que esta biblioteca es imprescindible. Pero como no estoy escribiendo demasiadas pruebas, personalmente no exijo ningún cambio.

Yendo más allá, no me importa participar en la vida del proyecto y compartir mi conocimiento, si corresponde. Si es necesario, también podría ayudar con el código/mantenimiento. Pero en este momento, desafortunadamente, no tengo la pasión y la energía suficientes para ser un mantenedor principal. Si tenemos algún candidato para eso en quien confiamos y que está lleno de pasión, definitivamente deberíamos invitarlo y convertirlo en uno de los mantenedores.

Primero, quiero disculparme con el equipo de @AutoFixture/core por no responderle en la discusión #703. Sí, fue un momento ocupado para mí (y todavía lo es), pero no estaba tan ocupado como para no poder responder. Simplemente no recibí ninguna notificación de ninguna de mis menciones y no pensé en revisar la discusión. Literalmente me acabo de enterar ahora que revisé el #703. De nuevo, lo siento. 😞

Mi posición sobre el futuro de AutoFixture es la misma que expresé en 2016 . Creo que AutoFixture es bastante estable y lo ha sido durante años. Si alguien quiere tomar una dirección diferente, creo que sería mejor comenzar desde cero. El concepto de autogeneración de datos de prueba es muy bueno y AutoFixture seguramente no es la _única_ forma en que podría hacerse en la plataforma .NET.

Eso no quiere decir que AutoFixture esté libre de errores. Lo que digo es que el volumen y el alcance del mantenimiento son lo suficientemente pequeños como para seguir siendo responsabilidad del equipo @AutoFixture/core.

¿Necesitamos un desarrollador líder? La historia del código abierto parece sugerir que un proyecto sin un líder individual eventualmente será abandonado. Pero, ¿qué pasa con un grupo de clientes potenciales?

Digo que tratemos de avanzar con el modelo actual sin un líder designado y veamos cómo va.

AutoFixture es un proyecto tan bueno que será muy triste verlo desaparecer lentamente.

Dado que @zvirja es el mantenedor principal/más activo del proyecto. Creo que tiene sentido que dirija cómo evolucionará este proyecto. Mantener un proyecto de código abierto requiere mucho esfuerzo y tiempo. Personalmente, no me importa donar para que este proyecto funcione. Y gracias @zvirja

Alguien debería señalar el elefante en la habitación, así que podría ser yo.

Este hilo se parece mucho a un funeral (o una perspectiva de arrepentimiento)

Creo que nosotros (la comunidad) deberíamos centrarnos más en encontrar una salida a la situación en la que nos encontramos que en lanzar disculpas.
Hasta ahora, este hilo ha sido muy bueno para señalar los problemas (no dude en completarlo):

1. Los mantenedores actuales no tienen tiempo/no están interesados ​​en el proyecto
2. El proyecto es difícil de mantener.
3. La revisión del código es demasiado restrictiva

Ahora, ¿podemos elaborar una lista de acciones que podemos tomar?

Si a alguien le importa, aquí está mi opinión sobre esto:

1. Aceptar nuevos miembros en la comunidad. @Kralizek ha existido por un tiempo, podría ser un buen candidato. ¿Quizás tener otro equipo junto a @AutoFixture/core?
2. Crear una acumulación de problemas, priorizar, pedir ayuda a la comunidad
3. Afloje la revisión del código. Uno no puede tomar la propiedad de un proyecto si el propietario anterior lo está constantemente abofeteando.
   Permita experimentos, tal vez cree un paquete adicional AutoFixture.Experimental , para las cosas, que aún no están confirmadas para llegar a la versión principal de la biblioteca (como Boost es para la biblioteca estándar de C++).

Estoy de acuerdo con @zvirja , el proyecto es muy intimidante. Descubrí AutoFixture hace unos dos años y solo recientemente tuve el coraje de enviar un PR.
Creo que hay otros que sienten lo mismo. Personas que están usando la herramienta y les gustaría verla prosperar.

Gracias @aivascu por señalar al elefante en la habitación.

Estoy de acuerdo con su análisis, pero también tendría una cuarta opción (aunque la odiaría): una nueva bifurcación para dar a sus mantenedores libertad para moverse y perder el tiempo.

Además, gracias por poner mi nombre en la lista, pero desafortunadamente no tengo tanta experiencia con las partes internas de la biblioteca y realmente no puedo moverme por ella.

Con mucho gusto puedo intervenir cuando se trata de la experiencia del usuario...

¿Qué tal un programa de patrocinio/respaldo para estimular el entusiasmo por mantener el proyecto?
Es un repositorio popular después de todo.

Mis dos centavos usando AutoFixture los últimos tres años:

Creo que la marca de AutoFixture es excelente. Es un nombre genial.

Es popular en Stack Overflow. [autofixture] tiene 506 preguntas, mientras que [xunit.net] tiene 801. Que sea casi tan popular como el marco de prueba casi oficial de .NET Core es bastante notable, y en parte se debe a la dedicación incansable de Mark. a la enseñanza (y ser un gran maestro). Y el blog de Mark es como una fuente de conocimientos sobre pruebas gratuitas.

Creo que la API de AutoFixture es bastante difícil de aprender.

Partes de AutoFixture que amo:

• Capacidad para usar el patrón de diseño de contenedor de simulación automática (probablemente el concepto de prueba más poderoso que me han presentado como ingeniero).
• Fixture.Freeze es increíble
• Extensión AutoMoq para permitir la creación rápida de accesorios para cosas que requieren un simulacro
• Capacidad para generar automáticamente un gráfico de objeto de entidad y probar mi patrón de Repositorio genérico y garantizar la cobertura de código de prueba de integración de extremo a extremo para mis repositorios de Entity Framework.

Partes de AutoFixture que nunca uso directamente:

• Accesorio.Inyectar

Partes de AutoFixture que quiero mejorar/ampliar

• Vea mi problema creado ayer: #1179
• Posibilidad de cambiar el comportamiento predeterminado de Guids por cadenas con algo más agradable, como Waffle Text Generator. Me doy cuenta de que puede hacer esto hoy, pero si se trabajó en # 1179, entonces podríamos conectar Selectores de elementos arbitrarios con un proveedor de datos personalizado.
• AutoFixture es lento y no utiliza trucos modernos para acelerar la compilación de expresiones, como lo hace el proyecto DryIoC de Maksim Volkau con FastExpressionCompiler de Maksim https://github.com/dadhi/FastExpressionCompiler

Partes de AutoFixture que no me gustan (en su mayoría menores):

• Accesorio.Personalizarsiempre funciona incorrectamente con Visual Studio intellisense.
• Escribir personalizaciones y por qué el método de personalización no le permite inyectar una personalización. Ese tipo de cosas son barrocas y molestas y crean una gran curva de aprendizaje.
• Las personalizaciones y los constructores de especímenes y cosas están por todas partes. Está desorganizado.
• Vocabulario extraño para algunas cosas.
• Es bastante difícil acostumbrarse a todo el patrón de diseño de Do..Without . Funciona, pero es detallado y no te ayuda con las entidades recursivas. Para eso, necesita Comportamientos especiales para decirle a AutoFixture que cree una tabla hash de objetos ya creados.
• Sin sintaxis simplificada para tareas comunes
• Diseño monolítico que requiere una comprensión profunda de las partes internas solo para resolver problemas. No puedes simplemente usar partes y piezas. Tienes que ver el curso PluralSight de Mark solo para superar la curva de aprendizaje inicial, o trabajar con un desarrollador experto en AutoFixture, para apreciar por qué AutoFixture es tan increíble.
• La postura de Mark de que AutoFixture solo debería generar "valores anónimos". Crea una gran cantidad de escritura de código de terceros para hacer las cosas. Los ejemplos incluyen las siguientes publicaciones de StackOverflow:
  
  
  
  • Autofixture, crea una lista de diccionariocon tecla alterna
  
  
  • ¿Cómo asigno una propiedad solo a un subrango de elementos en una lista?
  
  
  • ¿Cómo creo una lista de clases que siempre tienen un valor predefinido establecido en AutoFixture?
  
  

Piezas que veo posibilidad de innovación:

• A medida que C# se vuelve cada vez más funcional (coincidencia de patrones, tipos de registros, etc.), lo ideal sería que AutoFixture funcionara cada vez más como FsCheck y Hedgehog en F#.
• Sería bueno si AutoFixture pudiera cosificar algunos conceptos de prueba concólicos de FsCheck, como la función Arb.
• Use innovaciones como las discutidas en RLCheck para permitir que los ingenieros creen entradas de prueba diversas y súper robustas (¡Guid como cadena es un truco!) https://www.carolemieux.com/rlcheck_preprint.pdf

Creo que algunos de los problemas que describo aquí son por qué Microsoft no usará AutoFixture en ninguna de sus pruebas para .NET Core.

Parece que un tenedor experimental podría ser el camino a seguir. AutoFixture es uno de los pocos proyectos de código abierto que conozco que es de uso diario generalizado por parte de los desarrolladores, definitivamente puede beneficiarse de capacidades adicionales y facilidad de uso mejorada, y tiene una base de código de alta calidad detrás. No puedo imaginar que el interés sea bajo si se mitigaran las preocupaciones sobre la contribución y el cambio de dirección, que es lo que haría una bifurcación activa.

Parece que un tenedor experimental podría ser el camino a seguir.

¿Por qué querrías hacer eso? Tendrías que mantener ese tenedor. Si está dispuesto a hacer eso, ¿por qué no se convierte en el mantenedor de este repositorio?

En lugar de una bifurcación experimental, consideraría crear un nuevo repositorio (o seguir construyendo sobre este) para introducir las mejoras de calidad de vida que se discutieron anteriormente.

AutoFixture tiene una API poderosa que puede lograr mucho pero puede asustar a mucha gente. La mayoría de las cosas se pueden presentar como azúcar sintáctico simple.

para introducir las mejoras de calidad de vida

Renato ( @Kralizek ), ¿qué significa QoL? ¿Calidad de vida?

Sí.

Si está dispuesto a hacer eso, ¿por qué no se convierte en el mantenedor de este repositorio?

@ploeh , ¿cómo se da un paso adelante como mantenedor del repositorio? ¿Hay algún requisito?
Para ser honesto, mirando la lista actual de mantenedores, hay algunos zapatos grandes que llenar.
Me gustaría contribuir con AutoFixture, tal vez incluso como mantenedor (algún día) y estoy seguro de que hay otros, pero imagino que nadie sería aceptado para mantener un repositorio tan popular.

¿Por qué querrías hacer eso? Tendrías que mantener ese tenedor.

Estoy de acuerdo con esa cita. Cuando inicialmente propuse un paquete experimental, en este hilo, estaba pensando en una forma de mitigar los problemas que tenía @zvirja , mientras mantenía el repositorio. El paquete habría contenido funciones construidas sobre el núcleo de AutoFixture, no una bifurcación alterada. Algo como lo que describió @Kralizek .
Por supuesto, idealmente, no se necesitaría un paquete como este. Lo que creo que deberíamos resolver es el problema de las personas en lugar de un problema tecnológico.

Lo que creo que deberíamos resolver es el problema de las personas en lugar de un problema tecnológico.

No sé qué significa eso. Cuéntanos más.

Lo que creo que deberíamos resolver es el problema de las personas en lugar de un problema tecnológico.

No sé qué significa eso. Cuéntanos más.

Creo que lo que quiere decir es que AutoFixture necesita mantenedores comprometidos que se sientan libres de innovar sin temor a destruir una hermosa obra de arte, como dijo @zvirja en su comentario .

Es difícil sentirse comprometido con algo en lo que siente que sus manos están atadas por la sombra proyectada por decisiones y liderazgo anteriores.

Se rechazaron pocas ideas interesantes porque estaban en conflicto con las "viejas costumbres". Esto mataría la motivación de cualquiera. Desde ese punto de vista, un tenedor liberaría mucho de este equipaje.

OK, soy un tipo simple, solo quiero fusionar cosas como https://github.com/AutoFixture/AutoFixture/pull/928 . Como mencioné anteriormente, AutoFixture no tiene buenas formas de admitir la generación de valores únicos. El generador congruencial lineal multiplicativo parece una buena base para esta característica. Recientemente escribimos el nuestro y no éramos tan inteligentes como alguien que conocía este truco, y solo encontré el PR más tarde.

Estoy como, "Sí, hagamos más de estas cosas geniales".

¿Cómo se da un paso adelante como mantenedor del repositorio?

Básicamente declaras que estás dispuesto a asumir esa responsabilidad. Por lo que puedo decir, todavía tengo derechos de administrador para el repositorio, y aunque ninguno de los mantenedores actuales ha declarado explícitamente esto, tengo la impresión de que ninguno de ellos va a continuar con esto.

¿Hay algún requisito? Para ser honesto, mirando la lista actual de mantenedores, hay algunos zapatos grandes que llenar.

No te preocupes por el pasado. En este momento, si leo la situación correctamente, AutoFixture está muerto en el agua. A menos que alguien asuma la tarea de llevarla adelante, nada va a cambiar.

Así, puedes cometer todos los errores del mundo, y difícilmente empeorarás las cosas.

@ploeh si lo pones así, estaría feliz de dar un paso adelante como mantenedor y espero que otros también lo hagan.

@aivascu Gracias, eso es genial.

Les daré a los mantenedores actuales y hangarounds @zvirja , @moodmosaic , @adamchester , @ecampidoglio alrededor de 24 horas para comentar sobre esto, y si no veo ninguna protesta, les daré derechos de mantenedor.

@ploeh Sin objeciones por mi parte.
@aivascu Bienvenido a bordo. Espero que este proyecto te traiga la diversión que estás buscando 😊

@aivascu No soy mantenedor pero me encanta esta biblioteca. Solo hágame un ping si necesita a alguien para rebotar sus pensamientos.

@ploeh , @aivascu , bien por mí :+1: :rocket:

Me complace hablar sobre partes del código base en las que he trabajado, creado o contribuido. Si me perdí una solicitud de extracción (o un problema) en el que se me mencionó, házmelo saber.

@aivascu Mis mejores deseos para ti. Mi único consejo es que puede tomar alrededor de 6 meses por cada 20,000 líneas de código en una base de código, especialmente si no hay algunos "registros de decisiones de arquitectura" claros en un solo lugar. Por esta razón, en los proyectos que mantengo, comencé a escribirlos para que la gente entienda el "estilo" del código. Mark ha escrito estos, pero principalmente en su blog y/o StackOverflow. @moodmosaic ha hecho lo mismo. Diría que, en el futuro, cree una carpeta adr en la raíz del repositorio que documente cualquier justificación del diseño. Puede usar archivos .md para eso. Para tablas complejas, use tablas html en lugar de tablas de rebajas.

Gracias a todos por la calurosa bienvenida.
Creo que, para empezar, seguiré el consejo de @jzabroski y comenzaré a llenar los vacíos en la documentación para facilitar la incorporación de nuevos mantenedores y colaboradores.
En paralelo, tal vez pueda comenzar a quemar el trabajo pendiente existente.
Es de esperar que haya más miembros de la comunidad dando un paso adelante para llevar adelante esta increíble herramienta.

Felicidades @aivascu.

Siento que eres el desarrollador principal ahora. Digo esto porque siento que las cosas volverán al estado 'muerto' en el que están ahora, tan pronto como te detengas, así que te estoy mirando ahora :)

Espero que el equipo de Autofixture 'busque' nuevos miembros del equipo, para mitigar el riesgo del problema del viaje solitario mencionado anteriormente. Estoy feliz de contribuir solo si alguien pudiera echar un vistazo a este https://github.com/AutoFixture/AutoFixture/pull/1164.

@aivascu Le envié una invitación para unirse al equipo central de AutoFixture, pero la invitación aún está pendiente.

@ploeh Acabo de aceptar la invitación. ¡Gracias!

@aivascu 👍 Bienvenido al equipo.

Si hay algo más que pueda hacer para ayudarte, estaré encantado de hacerlo. Sin embargo, he estado inactivo en el proyecto durante años, por lo que ya no sé cómo funciona ninguna de las cosas prácticas. Espero que @zvirja pueda informarte sobre esos detalles.

¡Gracias!

Bienvenido @aivascu

@aivascu Me encantaría incorporarte al proyecto. Si no le importa, estaría muy feliz de tener una conversación de voz con usted, para poder mostrarle todo y responder a las preguntas. Si está dispuesto a hacerlo, escríbame un correo electrónico (puede encontrar la dirección en las confirmaciones) para que podamos acordar los detalles.

Y bienvenido de nuevo.

@zvirja eso sería muy bueno. Te enviaré un correo electrónico.

Bienvenido @aivascu :+1:

¡Bienvenido a bordo, @aivascu! 🙂

@aivascu Dado que te presentaste como un nuevo mantenedor lleno de pasión y energía para trabajar en esto, ¿deberíamos cerrar y desanclar este problema? ¿Es como decir que por ahora nuestro futuro está determinado? 😄

@zvirja Esperaba que alguien más solicitara llenar las filas de mantenedores. 😄

Si alguien siente que podría disfrutar siendo un mantenedor de este repositorio, abra un problema o envíenos un mensaje.
Voy a cerrar el tema ahora.