Esta página esta siendo tocada. Disculpa si las cosas no se ven como siempre.

Etiqueta: test

  • Este post está escrito utilizando org2blog, un paquete para GNU Emacs que permite enviar buffers en formato Org a un sitio web de WordPress usando la API.

    Estoy probando GNU Emacs estos días otra vez. Ya lo probé hace un par de meses pero acabé dejándolo de usar. Realmente me sigue dando cierta curiosidad sana ver cómo son las cosas en Emacs.

    A pesar de que con los años en Vim se han incluido funciones como terminales en línea, y de que existen plugins para trabajar con Git desde hace bastante tiempo, en la práctica suelo encontrar tanta fricción que al final mi forma de trabajar suele ser tmux + vim dentro de un pane, para poder abrir panes auxiliares cuando necesito escribir comandos.

    Me da cierta curiosidad como en Emacs las cosas se integran de forma tan natural y cómo el sistema reacciona mejor a cosas como intentar leer el e-mail o documentos web desde dentro del editor de textos, y eso es lo que me ha llevado a volver a intentar probarlo, con un poco más de calma.

    Esta es la lista de cosas que me atraen de GNU Emacs:

    • Org-mode, aunque tengo que aprender a usar las funciones de lista de tareas, calendario, agenda, pomodoro… O sea, todo lo que no es escribir.
    • Org-babel, que permite hacer programación literaria. Por ejemplo, el archivo de configuración de mis dotfiles de Emacs es un archivo .org con bloques de código metidos entre prosa. Con un comando es posible extraer esos bloques de código y evaluarlos por separado.
    • Por alguna razón, los plugins para desarrollo de Ruby on Rails funcionan con menos fricciones que sus equivalentes para Vim.
    • Por alguna razón también, esta gente ha solucionado de una forma limpia el problema de los language servers, a diferencia del espectáculo que encuentro en Vim.
    • Repositorios de paquetes, que se integran en la aplicación (MELPA).
    • nyan-mode.

    Esta es la lista de cosas que me generan cierta incomodidad en GNU Emacs:

    • No es un editor modal.
    • Atajos crear una línea en blanco encima o debajo de la que estás, un poco complicado de simular pero lo conseguí.
    • Invitación a padecer túnel carpiano.

    Esta es una lista de cosas que me gustaría aprender a partir de aquí:

    • Elisp.
    • Leer e-mail.
    • Leer feeds RSS.
    • Lo de la org-agenda.
  • El otro día respondí lo siguiente por nuestro Discord en un hilo [1] en el que se debatía si era 100% necesario escribir tests a la hora de escribir un código. Traigo el contenido aquí para no perderlo en el historial y tenerlo a mano.

    Yo me voy a tirar a la piscina y voy a decir que sí es posible escribir el código de un proyecto sin tests si lo pruebas a mano según lo estás desarrollando.

    Lo que no es posible hacer sin tests es mantenerlo. Porque cuando se hagan cambios en el software ya no va a ser el mismo software que el que has probado a mano cuando lo estabas desarrollando. Tendrías que probar a mano de nuevo todo el programa, y eso puede ser una pérdida de tiempo. ¿Cuándo entra un código en mantenimiento? En cuanto dejas de tener visible ese código después de escribirlo.

    Creo que la principal finalidad de los tests desde el punto de vista pragmático, más allá del «virtuosismo» de «soy guay, tengo tests, tengo buen coverage (JA)», es poder automatizar el poder comprobar que el software sigue funcionando bien conforme va pasando el tiempo de una forma automática y no intrusiva. Si hago un cambio de mantenimiento a un módulo de software quiero poder tener mi checklist ya implementada que me cubra todos los casos de uso de ese módulo de software para poder hacer la validación automáticamente y comprobar que no se introducen regresiones, o sea, que no he roto nada inesperado al hacer el cambio. (El software a veces se conecta de formas poco esperadas; cohesión siempre acaba habiendo y las interfaces de un módulo nunca son tan buenas como cabría esperar)

    [1] Para que este deeplink funcione hay que haberse unido antes al servidor.