🧙 ⛴️ 🕎 Cómo hacer que un auto escriba pruebas del código para usted 🏄 🐟 🌷

Vivimos en un mundo imperfecto. Las personas escriben código aquí, y las personas son naturalmente propensas a cometer errores . Todo estaría bien, los errores pueden detectarse en la etapa de prueba y no se puede dañar a nadie. Es posible si escribes pruebas. Lo que a la gente no le gusta hacer por alguna razón. Pero quizás haya esperanza: autogeneración de pruebas a partir de código escrito.

Julia Volkova quiere probar la idea en realidad y está tratando de cambiar la creación de pruebas basadas en código a una máquina, sin usar instrucciones o contratos adicionales. Julia le contará sobre los descubrimientos que el viaje trae al mundo de la metaprogramación, AST, análisis y tokenización, y lo que todo esto nos ha permitido lograr en la autogeneración de pruebas, en Moscow Python Conf ++. Mientras tanto, pregunté de dónde surgió la idea: automatizar las pruebas, cuál es la base del prototipo y qué queda por hacer.

Julia Volkovaxnuinside) Senior Python Developer GridDynamics. pet-, . , legacy-, , . , «» . -, .

— , , , ? , . ?

- Creo que hay varias razones. Primero, la mayoría de nosotros somos flojos en la naturaleza. A pocas personas les gusta escribir exámenes directamente: se despiertan por la mañana y dicen: "Debemos comenzar el día con 15 exámenes, de lo contrario todo será malo, pero al mismo tiempo mi vida no tendrá éxito". La pereza natural se manifiesta con mayor frecuencia, especialmente cuando ve que el método no es muy interesante, tiene un código claro y primitivo, pero aún necesita cubrirlo con pruebas.

Pocos escriben TDD, por lo que no solo tiene que escribir una prueba, sino que también debe dedicar tiempo al código.

El problema es que no se asigna una cantidad infinita de tiempo para el desarrollo. Siempre hay productos de lista de deseos por tiempo limitado. En general, en los equipos de productos, todo era necesario ayer, porque el tiempo es dinero. A los gerentes les parece que cuanto más ecologicemos una característica, más caro y mejor será nuestro producto. Y no siempre es obvio que probar la cobertura, la calidad del código afecta directamente la velocidad posterior de agregar funciones, soporte de código, actualización, etc.

A menudo culpamos de todo a los gerentes y decimos que no nos dan suficiente tiempo, de lo contrario nos sentaríamos y escribiríamos exámenes. De hecho, este no es siempre el caso. Y no siempre los desarrolladores robustos experimentados dicen escribir pruebas, y los colegas más jóvenes no quieren hacerlo.

He estado en TI durante mucho tiempo, pero he estado directamente involucrado en el desarrollo durante 3-4 años. Antes de eso, trabajé más en puestos gerenciales y vi diferentes desarrolladores. Hay muchas personas a las que no se les puede llamar inexpertos porque llevan 10 años escribiendo código, pero al mismo tiempo creen que las pruebas como tales no son necesarias. Suponga que no necesita cubrir el código con pruebas unitarias, porque hay un ingeniero de control de calidad que necesita detectar errores. Y no creen que un ingeniero así pueda cubrir no todos los casos con pruebas de extremo a extremo.

"Si no vas a tales extremos, ¿qué piensas, quién debería escribir las pruebas?" ¿Debería ser el programador mismo, el junior o, por el contrario, el desarrollador más genial del equipo?

- Si hablamos de pruebas unitarias, definitivamente no debería ser QA. Estas definitivamente deberían ser aquellas pruebas que se verifican, pasan y escriben antes de los commits. Deben dirigirse a la solicitud de extracción, en ningún caso otra persona debe escribirlas más tarde. Por ejemplo, yo, como desarrollador perezoso no junior, simplemente pondría a juniors a escribir pruebas para código primitivo. Hay cosas para las cuales es suficiente simplemente leer el código en un nivel intermedio y escribir afirmaciones, tal trabajo es bastante adecuado para los juniors y será útil para su desarrollo.

Estas son pruebas unitarias que simplemente cubren el código de estado tal como está. Estas pruebas no verifican cuán válida es la función en relación con el requisito de la tarea en la tarea, pero solo se aseguran de que el código haga lo que hace y lo hace correctamente ...

Sin embargo, para verificar la validez del código para los requisitos comerciales, para la lógica comercial, una persona que implemente estos requisitos debe hacerlo. Debe comprender qué y cómo lo cubre con las pruebas. Pero no está claro cómo ayudará si una persona no entendió inicialmente el problema, escribió un método que lo resuelve incorrectamente, pero realizó la prueba correcta para este método incorrecto.

- Podemos decir que el problema es que la gente tiene una mala idea de cómo va el proceso de desarrollo de software.

- Esto es muy subjetivo. Te imaginas a ti mismo como una unidad de desarrolladores que entienden que las pruebas son necesarias, por qué son necesarias y piensas que eso es cierto y bueno. Pero hay una capa bastante grande de desarrolladores que creen que esto es redundante. Y, en cierto sentido, los gerentes probablemente tengan razón a su manera cuando dicen que las pruebas no necesitan cubrir todo el código, solo las pruebas manuales en la etapa son suficientes.

No siempre es correcto decir que una persona a la que no le gustan las pruebas es un desarrollador no calificado.

Él tiene una visión propia, y no para que yo juzgue. Todavía me encuentro a menudo con desarrolladores que han estado escribiendo código durante 10 años y digo que es redundante cubrir todo con pruebas unitarias, suficientes pruebas de humo y trabajo de control de calidad son suficientes.

Yo, a su vez, me siento incómodo en un proyecto en el que no hay pruebas unitarias para las funciones. Es importante para mí que haya al menos pruebas que garanticen la protección contra el factor humano, capaces de detectar una coma colocada al azar o un nombre clave cambiado en un dict. Pero no me gusta dedicarle tiempo, porque siempre quiero hacer más tareas "inteligentes". Por lo tanto, estoy pensando en herramientas para automatizar el proceso de redacción de pruebas.

- ¿Crees que Python se tipea dinámicamente y no verifica nada en la etapa de compilación? ¿Podría ser más fácil en otros idiomas con esto?

- Creo, jugadas, y fuerte. Esta es una historia eterna sobre los tipos, pero con el advenimiento de las anotaciones de tipos es más fácil trabajar con ellos.

Por ejemplo, en Python puede haber cadenas de funciones anidadas, donde lo esperado al final de la lista por alguna razón se convierte en un diccionario. Es posible que la ejecución nunca llegue a la función final, pero en algunos si, en algún caso excepcional, lo hace, y luego aparecerá un error.

Por supuesto, con un lenguaje escrito esto no puede suceder en principio, porque ya se producirá un error en la etapa de compilación. A este respecto, por supuesto, Python proporciona formas adicionales de dispararte en el pie (en la cabeza y en cualquier otro lado). Especialmente si trabaja con proyectos grandes con lógica ramificada, donde los datos se pueden verter en diferentes variaciones, en diferentes agregaciones.

- ¿Qué, pues, estar con la tipificación? ¿Crees que escribir debe ser al máximo o al mínimo? ¿Cuál debería ser el equilibrio de escribir en código dinámico?

- Esto es nuevamente bastante subjetivo. Muchas personas vinieron a Python precisamente porque no hay mecanografía y porque todo es muy flexible y conveniente. No debe olvidarse de esto y no descartar una gran capa de desarrolladores, incluidos científicos de datos y analistas que también escriben código. Supongamos que, como desarrollador de back-end, por supuesto, me siento más cómodo cuando la escritura está generalmente en todas partes. Idealmente, mypy también funciona.

Pero en la mayoría de los proyectos en los que participé, esto no es posible. Debido a que el proyecto también tiene analistas de datos que dicen que porque escriben en Python porque no quieren meterse con los tipos, es muy conveniente para ellos.

Una gran cantidad de personas cree que además de Python en ausencia de tipos y mecanografía.

Necesita crecer hasta cierto nivel para comprender cuándo y por qué se convierte en un signo menos. En algunos pequeños scripts de Python o en pequeños proyectos, tampoco uso tipos, porque sé que en un script de 2 funciones, los tipos no son particularmente necesarios. Pero esto es algo que, en términos generales, hice rápidamente sobre mi rodilla para sacar algo de la base. Y en proyectos más grandes, trato de agregar tipos al máximo en todas partes, si no hay resistencia de otros desarrolladores.

- Estoy completamente de acuerdo contigo en esto. Solo queda entender cómo usar los tipos, porque este es un tema oscuro separado.

: «, Haskell , : , . Python , , ».

— . , , legacy- smoke-. . ?

- No diré que mi enfoque es mejor, simplemente es diferente. Cubrir su código con pruebas de humo es bueno cuando puede. Mi proyecto anterior fue el dolor por excelencia asociado con las pruebas. Era una plataforma de ciencia de datos de 8 microservicios y 20 mil líneas de código. El problema es que la plataforma recibe una gran cantidad de datos y características para vehículos, estaciones y ciudades, varios estacionamientos y tipos de suministros, agrega y crea un enorme conjunto de horarios potenciales para estos vehículos en todo el mundo. El cronograma tiene en cuenta una gran cantidad de condiciones de la categoría en la que puede repostar el vehículo, donde hacer una parada intermedia.

Hay muchos métodos diferentes en el sistema que se pueden usar en 1-2 situaciones, que, quizás, ninguno de los clientes recordará nunca. Luego, escribir pruebas de humo de hecho se convierte en pruebas de escritura para todo el sistema, teniendo en cuenta todas las funciones y sus combinaciones.

La prueba de humo debe verificar que todo funcione en la salida y que no se rompa mínimamente. Una prueba de humo muy primitiva que el sistema inició y de alguna manera funciona no aporta ningún beneficio en nuestro caso. Digamos que verificamos que hay una conexión con la base de datos, algo está comenzando, la interfaz de usuario está obteniendo algún tipo de API. Y luego un paso hacia la izquierda, un paso hacia la derecha, y nada funciona. Es decir, hay una prueba de humo, por así decirlo, pero los errores aún salen de la producción.

En este sistema, las pruebas unitarias funcionaron bien: cuando se monitoriza claramente que las funciones no han cambiado, no se han roto después de algunos cambios en el código. El código también es diferente. Diferentes proyectos, diferentes tareas necesitan diferentes enfoques para las pruebas.

La idea en la que estoy trabajando actualmente solo se puede llamar condicionalmente la generación automática de pruebas. Es más bien una herramienta de desarrollador. Quiero obtener una herramienta que escriba pruebas para mí y ejecute todo el código que puede ejecutarse sin mí.

Daré un ejemplo. Hay una pequeña función que toma un diccionario, de ahí algún valor y una clave. Esta clave es muy importante para los negocios, pero desde el punto de vista del código es una operación bastante primitiva: tomar del diccionario, incluso si es una clave anidada varias veces; compruebe que está allí, que no es cero; cámbielo o tal vez solo devuelva el valor. Este es un código bastante primitivo precisamente desde el punto de vista de AST. No quiero perder el tiempo con él y escribir exámenes. Quiero que el auto lo haga por mí.

Este es precisamente un metaprograma con un código de entrada y un código de salida. Digamos, al módulo py, que dice: "Aquí tengo una afirmación, te" ayudé "de que hay errores de elevación en esta condición, valores válidos devueltos en tal situación, algo más sucedió con tal argumento" . Es decir, de hecho, hace el trabajo donde yo mismo miraría lo que se alimenta a la entrada de la función y lo escribiría en la prueba.

Quiero que el programa genere lo mínimo que pueda ejecutar para mí. Pero este debería ser un archivo de prueba, en el cual, si lo desea, puede cambiar o expandir algo. Que puedes comprometer en Git, prueba de prueba, etc.

- ¿Cuánto puede confiar en tales pruebas autogeneradas? ¿Qué quiero decir? ¿Cuánto están vinculados a una implementación específica y cómo se comportarán bajo cambios normales en la lógica o refactorización de negocios?

- La idea es tomar el código en la forma en que está ahora, y basarse en él para generar pruebas válidas en este momento.

Por supuesto, puede volver a generar las pruebas cada vez, pero esto no será correcto, porque entonces no habrá seguimiento del estado del cambio de código. En consecuencia, todavía hay diferencias de prueba para esto, es decir, las pruebas se generan solo para lo que no ha sido cubierto por las pruebas antes. Y las pruebas ya creadas deben ser respaldadas por usted mismo.

Tal vez esto sea una pequeña paranoia, pero hasta ahora dudo que con la generación automática sea posible garantizar que al regenerar las pruebas no cubra el código válido con pruebas válidas. Una cosa es que en febrero de 2019 generé pruebas, y si cambias la lógica, las cambias tú mismo, porque sabes qué cambios se han realizado. Usted sabe por qué cayeron las pruebas y puede corregir las pruebas en consecuencia. Y es un asunto completamente diferente cuando los regeneras cada vez. Las pruebas serán válidas, pero solo para ese estado modificado del código.

Quiero obtener una herramienta para el desarrollador, y no una pieza para aumentar la cobertura del código.

- ¿Cuáles pueden ser las métricas de éxito? ¿Cómo entender que generamos pruebas bien?

Voy a nombrar a lo que presto atención, sin lo cual me parece que las pruebas no tienen sentido. Es imperativo que todos los casos de comportamiento de código descritos por el desarrollador se procesen en las pruebas. Por ejemplo, si hay un if que no devuelve nada, pero escribe un registro, en la prueba este registro debería funcionar. No solo que la gente escribe advertencia e imprime. En consecuencia, si en algún lugar hay un procesamiento de aumento de error, debe resolverlo en una prueba. Si el aumento repentino desaparece, es decir, habrá un cambio en la lógica del código, entonces esto también debe resolverse.

Del mismo modo, si hay sentencias if, entonces debe haber procesamiento en la afirmación de cada condición. Entonces la prueba estará más o menos cerca de la verdad. Y no olvide que todo esto debería comenzar, y no solo emitir "éxito" en PyTest con cuerpos de prueba vacíos.

- Dime cuán difícil es técnicamente hacerlo. Suena como una tarea bastante difícil.

Sí, esta es una tarea muy difícil, y probablemente sea este hecho y varias otras circunstancias las que me han llevado a hablar de esto en un informe sobre Moscow Python Conf ++. Quiero plantear este tema, interesar a otras personas en él y discutir soluciones con ellos.

Tengo la sensación de que nadie acaba de intentar hacer esto, porque la tarea es difícil. De lo contrario, habría algunos artefactos en la red, como código, descripciones, artículos, o al menos menciona que existió, pero fue abandonado.

Para comprender lo difícil que es esto, recordemos cómo funciona el intérprete. Hay operaciones, declaraciones en el código, el intérprete las realiza (bueno, no bueno, falló, no falló) y produce el resultado. Además, el desarrollador agrega manualmente nuevos argumentos, inicia el intérprete nuevamente y se asegura de que todo tenga éxito ahora. Pero cuando intenta generar pruebas para el código, primero debe pasar por el árbol AST y comprender qué pasos debe seguir para obtener el resultado.

Una función puede tener muchos grupos de argumentos, estrategias para argumentos y muchos resultados para estas estrategias. Hablando de estrategias, quiero decir que, digamos, las hay if arg_1==1: raise error. Esto significa que hay algunos grupos arg_1=1para los que la función siempre devuelve un error. Pero con el argumento, el arg_1>2resultado de la función será diferente, y se creará un segundo grupo, la segunda estrategia.

En consecuencia, necesitamos encontrar y resaltar todos esos grupos de argumentos (si, por supuesto, lo son), en los que la función cambia su comportamiento. Y luego siga la cadena de acciones: lo que sucederá dentro de la función con estos argumentos para obtener el resultado final.

Además, no olvidamos que además del hecho de que hay algún argumento, también hay acciones dentro de la función, por ejemplo, asignar variables, llamar a otras funciones. Es decir, también obtenemos un gráfico de las dependencias de los métodos en los métodos, cuando para verificar algún código primero debe obtener el resultado de otro código.

En consecuencia, para generar pruebas, primero debe obtener toda la información necesaria del árbol AST y luego generar argumentos, parámetros y datos para cada estrategia. Con ellos, repase toda la cadena de acciones, obtenga el resultado, y solo entonces tendremos una prueba válida con diferentes afirmaciones. Ésta es una tarea difícil.

No creo que algún día sea posible cubrir al 100% todo tipo de casos automáticamente, por ejemplo, para los enormes lienzos de los códigos fuente de Django. Es laborioso pero interesante. Hasta ahora tengo curiosidad de saber dónde tengo la paciencia y la fuerza para llegar.

- ¿Hay algún ejemplo de otros idiomas y áreas donde funcione algo como esto?

- No se conocen otros similares. Creo que es más fácil escribir una prueba que cortar una herramienta especial.

Pero tengo la sensación de que tarde o temprano automatizaremos lo que ya estamos haciendo bien.

Hay un gran grupo de desarrolladores que escriben bien las pruebas unitarias. Tenemos suficientes competencias en el desarrollo de Python para querer escribir una herramienta o biblioteca que lo haga por nosotros. Y escribiremos cosas más complejas, pruebas más complejas.

Hay algún tipo de generación de pruebas en Java, C y .Net. Pero allí, también, todo se basa más en la propiedad o en el contrato. En C, hay una generación de prueba de carácter por símbolo, parece que solo mira el código y, sobre la base de esto, hace algunas pruebas. Pero este es un nivel de abstracción tan diferente en el lenguaje mismo que no estoy seguro de si se trata de una historia similar.

Si hubiera algo muy similar, entonces, por supuesto, uno podría adoptar algo, echar un vistazo.

- ¿Cree que los marcos o las técnicas para escribir código Python simplifican o complican la tarea de generar pruebas desde el árbol AST?

- Es difícil decir si en este sentido es muy diferente simplemente importar alguna biblioteca o usar un marco directamente específico. Absolutamente, puede complicar en gran medida el trabajo de algo que cambia el comportamiento de la interpretación de un proceso de código, por ejemplo, una extensión C. Todavía no sé cómo lidiar con esto, pero el uso de mis terceros paquetes favoritos hasta ahora en este problema se basa en la necesidad de resolver las importaciones. Todo es simple con los paquetes integrados, pero con las importaciones todo se vuelve más complicado. Mypy tiene algunas ideas e implementaciones, pero todavía no toco el historial de importación de paquetes de terceros.

- Quizás sea algún tipo de técnica, mucha dinámica, el uso de getattr, ¿algo así? ¿O está funcionando bien?

"Simplemente funciona perfectamente bien". Porque getattr o manipulaciones con metaclases son visibles en AST. Sí, deben resolverse, y esto agrega cierta complejidad. Pero esto se rastrea de todos modos.

- Ya hemos dicho que las pruebas autogeneradas están destinadas principalmente a personas. ¿Cuán legibles serán para las personas? Habrá mucha lógica dentro de cada prueba, ¿afirman? ¿Cómo será la separación entre el código y los datos, cómo lo ve?

- Ahora trato de agregar inicialmente todo tipo de cosas banales a las pruebas. Supongamos que, si se trata de algún tipo de error de subida, entonces no es solo con subida, sino que al menos deja un comentario, qué tipo de error, por qué aparece, para que la persona, después de leer la prueba, comprenda qué sucedió realmente, qué argumento lleva a qué error .

Afirma hasta ahora combinado en un método. Es decir, si hay una función y hay 5 estados que queremos verificar, entonces hasta que 5 afirmaciones entren dentro de la función.

Hubo una idea para introducir convenciones de nombres, por ejemplo: poner errores al final del error, los registros de prueba también tienen algo propio. Pero lo he pospuesto por ahora, porque la cuestión de cómo crear el tipo final de pruebas en el código, directamente un bloque de texto con pruebas, es la operación más económica. Si la idea parece repentinamente que todo necesita ser reformateado, entonces esto será fácil de hacer: hay conjuntos ensamblados listos para usar, solo necesita elegir un aspecto diferente para las pruebas.

- ¿Apoya unittest o pytest?

- Pytest. Y solo porque no quiero gastar mucha energía en la producción ahora. Pytest es bueno porque hay muchos complementos, decoradores, varios modificadores que son fáciles de usar.

La belleza puede ser importante tanto para el usuario final como para el desarrollador. Pero esto no afecta el desarrollo de la idea en absoluto. Si necesita admitir unittest, esto se puede agregar fácilmente.

- ¿Cuánto se relaciona este enfoque con las pruebas basadas en propiedades?

- Ahora, para generar argumentos, solo se usa el tipo moki: necesita int, dar int aleatorio. Pero tales estrategias serán fáciles de reescribir, por ejemplo, comenzar a usar hipótesis. Si bien no paso mucho tiempo y esfuerzo en esto, porque entiendo que puedo usar generadores de terceros por valor. Ahora, me parece, esto no es tan importante como trabajar con AST.

- ¿Planea apoyar la programación de contratos o separarse de alguna manera especial? Porque ayuda mucho trabajar con pruebas unitarias, pruebas basadas en propiedades y pruebas, en principio, para comprender la lógica empresarial.

- Si por programación de contrato nos referimos a contratos en el código, entonces me alejo de esto tanto como sea posible. Porque cuando puede usar la programación de contratos, básicamente puede codificar los contratos con contratos y generar pruebas unitarias en función de ellos. Y entonces mi herramienta no es tan necesaria.

Ahora trato de no pensar en nada que modifique el código. Porque, por ejemplo, en proyectos de outsourcing, en los que enfrenté el problema de la falta de pruebas, y estos fueron casi todos los proyectos, lamentablemente, en la empresa actual, fue casi imposible tocar el código. Es decir, era imposible hacer cambios hasta que pudiera garantizar que este decorador o contrato no cambiaría todo el componente funcional del código.

Si es posible editar el código, las pruebas de contrato son buenas.

Pero por ahora, procedo del hecho de que no existe tal posibilidad. Y así, de hecho, sobre la base de los contratos, puede generar pruebas unitarias y, de hecho, implementar la duplicación de la funcionalidad.

- Cuéntenos sobre el siguiente punto importante: ¿cómo evaluar las pruebas recibidas y cuánto puede garantizar que estas pruebas realmente prueben algo?

- Las pruebas de mutaciones no se han cancelado, y en una imagen ideal del mundo, sin duda, debe usarse en esta historia. La idea en su conjunto es la misma que si la prueba fuera escrita manualmente por el desarrollador. Es decir, todo lo que está disponible para las pruebas de prueba se puede aplicar completamente.

- Ahora hablemos un poco de la conferencia de Moscú Python Conf ++. Vamos a realizaruno de los desarrolladores de hipótesis que mencionamos varias veces. ¿Qué le interesaría preguntarle?

- Me gustaría preguntarle a Zach sobre dónde quieren desarrollar el proyecto junto con los encargados del mantenimiento: qué agregar, qué forma de desarrollar. Sé con certeza que Zach ahora tiene un PR para la generación de pruebas. Lo hacen regularmente. Más precisamente, los decoradores se suman a las pruebas unitarias existentes.

Me gustaría discutir las ideas de la generación automática de pruebas en términos de cómo la hipótesis la ve, cómo la ven los contribuyentes. Seguramente las personas que participan en pruebas a ese nivel tienen algunas ideas o tal vez alguien ya ha intentado algo.

“Contamos con esto cuando estemos preparando el programa de la conferencia: para que los informes establezcan temas de discusión, durante los cuales todos encontrarán nuevas ideas y direcciones para el desarrollo. ¿A qué informes irás?

- Me gustaría enfadarme e ir a todos los informes a las 12 en punto. En este momento, estarán Zac Hatfield-Dodds, Andrey Svetlov con un informe sobre programación asincrónica y Vladimir Protasov con automatización de refactorización . Voy a ir a algunos de los dos últimos, y luego venir corriendo a Zack al final del informe ( Ed.:. Tomar la vida piratería en servicio - Casi escuchar un nuevo tema, y al altavoz, con quien desea hablar, llegar al final del informe y preguntas ) .

Debe haber muy interesanteinforme sobre validación de datos , me interesa directamente. Y hay dos informes más a los que también iría, pero todos irán en paralelo con el mío: este es un informe de Vitaly Bragilevsky sobre mecanografía y Christian Heimes sobre el perfil . Lamentablemente, no puedo llegar a ellos de ninguna manera.

- Cuéntame un poco más sobre el tema de tu informe, ¿por qué estás haciendo, qué estás haciendo, por qué estás hablando y qué estás esperando del discurso?

- Quiero más herramientas para automatizar los procesos de desarrollo y más colaboraciones relacionadas con esto. Existe tal actividad, pero en el contexto de escribir constantemente el mismo código, me parece que debería haber más.

Como dije, no hay experiencia abierta en pruebas de autogeneración en Python. No está claro si alguien estaba haciendo esto, de ser así, por qué no despegó, no fue. No sé hasta qué punto la generación de pruebas basadas en AST será relevante para la comunidad, hasta dónde puede llegar. Ahora estoy haciendo esto porque estoy interesado en el proceso en sí, estoy interesado en cavar a través de árboles AST, aprender más sobre cómo funciona el código Python y encontrar muchos matices diferentes que no son obvios cuando se trabaja con el código de nivel superior. Trabajar con árboles AST trae muchos descubrimientos repentinos.

Quiero que las personas tengan ideas después del informe, por ejemplo, cómo automatizar algo que usan en su trabajo. Para que algunos de ellos dejen de escribir fragmentos de código que ya escriben todos los días y comiencen a generar o reducir la cantidad de tiempo para escribirlos. Espero que alguien salga con una nueva comprensión de cómo resolver este problema.

- ¿Dónde te tomas el tiempo para hablar en conferencias, escribir tus propias bibliotecas? Esta pregunta en realidad aparece constantemente, muchas personas se quejan de que no tienen tiempo para nada.

- En primer lugar, sobre la hora. No soy un empleado muy conveniente para muchas empresas en el sentido de que no hago cosas que me parecen ineficaces. Intento hacer cosas que realmente me interesan o que puedo hacer de manera efectiva y correcta. Si, por ejemplo, un gerente quiere que repare algún tipo de error en este momento, que en realidad no es un error, sino una lista de deseos nueva del cliente, no me sentaré y arreglaré todo, porque sé que el cliente volverá y dirá por qué lo hizo.

Intento no hacer un trabajo innecesario en el trabajo, no hacer lo que implicará la pérdida de mi tiempo después.

Supongamos que si me piden que despliegue el viernes, les digo: "Chicos, los quiero mucho a todos, todos ustedes son excelentes compañeros, pero si necesitan desplegar algo ahora, desplácese usted mismo y me iré a casa". Puedo implementarlo el lunes, podemos hablar sobre por qué se ha producido una situación así, que desea implementar ahora el viernes ". Puede ser doloroso por primera vez decirle esto al cliente o a los gerentes, pero más tarde la gente se acostumbra, aprende y no le pide que haga algo muy urgente el viernes por la noche. Entienden que, en primer lugar, nadie murió el viernes pasado, cuando nadie se inundó, e incluso nadie perdió dinero. Intento no hacer algo que me haga daño.

La misma historia sobre errores: si hay muchos errores que deben corregirse constantemente, la pregunta es: ¿por qué aparecen estos errores? No debemos solucionarlos, pero piense por qué hay tantos, de dónde provienen y luchan principalmente con el problema raíz. Estos también son siempre problemas dolorosos, cuando un gerente o cliente dice que es urgente corregir una característica en la producción. Pero debe poder decir que si toco este código ahora, entonces quizás tenga algo más que esta característica, no tendrá producción, ya que el código no está cubierto por las pruebas, no puede agregar otro si, porque No recordamos lo que hacen los otros seis.

A veces necesitas superarte y comenzar a hablar. Esto no siempre es posible, es necesario crecer hasta un cierto nivel de conciencia de que por cuánto tiempo pasas en qué tipo de trabajo, eres responsable.

Por lo tanto, probablemente tenga tiempo. Debido a que trato de optimizar mi tiempo de trabajo, hacer que me tome un cierto número de horas completar una tarea. Al mismo tiempo, entiendo que en una buena estructura debe haber 1-2 horas para la deuda técnica y algunas mejoras.

No diré que trabajo 8 horas sin levantarme. Me gustaría ver a un desarrollador que se sienta y escribe código durante 8 horas de tiempo de trabajo. Si toma mi día de trabajo habitual, 2 horas son solo todo tipo de pruebas, revisión de código, deuda técnica, "zumbido" en el código. Hours 3 es una solución a los problemas actuales, una hora para comunicarse con los gerentes. Y las 2 horas restantes se extienden por alguna razón, para discusión con equipos y cosas independientes.

Hay cosas que le interesan hacer: lo hace, y cuando no tiene fuerza, le dan fuerza. Tengo muchas actividades diferentes, esto probablemente se llama dilación útil, cuando hago lo que me interesa en este momento y no lo que necesito hacer. Si aprende a variar entre lo que es interesante y lo que aún se necesita, resulta ser el más exitoso. Simplemente no pierdas el tiempo perdiéndote a ti mismo para hacer lo que no quieres.

No hay ningún secreto, solo debes hacer lo que quieras, pero al mismo tiempo sin dañar a los que te rodean y al proyecto.

Para obtener detalles sobre la implementación de la generación de pruebas a partir del código Python, así como para resolver muchas otras tareas de un desarrollador de Python, visite Moscow Python Conf ++ , que pospusimos para el 15 de septiembre.

Cómo hacer que un auto escriba pruebas del código para usted

More articles: