La presente lista se utilizará para organizar y coordinar el trabajo que se llevará a cabo en la DrupalConTribute Twitter. Es imporante confirmar la participación apuntándose en dicha página.
Bugs
Actualmente hay 383 issues pendientes. Las que son prioritarias son aquellas que informan bugs en el módulo. El procedimiento a seguir al leer una issue es el siguiente:
- Leer la descripción detalladamente y simular un entorno similar al descrito en la misma (ej: hacer un "git checkout de la versión correspondiente del módulo").
- Intentar reproducir el error. Si no se puede, pasarlo a "posponed (maintainer needs more info)" y sugerir al creador que dé más información.
- Si se puede reproducir, comprobar si el error se produce en la rama de desarrollo (6.x-3.x o 7.x-3.x).
- Si no se produce: sugerir al creador que actualice el módulo y pasar a estado "fixed"
- Si se produce: revisar el código para corregirlo y generar un parche. El parche se adjuntará y se pasará al estado "needs review". Otra persona tendrá que verificar que el parche corrige el error, en cuyo caso se pasará al estado "reviewed and tested by the community".
- Se debe verificar también que el error no se produce en la otra versión de Drupal (si estamos viendo un bug de la versión 6.x-3.x, ver que no se produce en la 7.x-3.x y viceversa). En caso de que se produzca, se deberá generar un parche también para esta versión.
Listado de bugs activos en el módulo.
Tareas pendientes (tasks)
Las issues de tipo task son tareas pendientes que deben realizarse y que no encajan en ninguna de las otras categorías. Tales como funcionalidad que todavía no ha sido migrada a la versión de Drupal 7.
Listado de issues de tipo "task" pendientes.
Soporte
Existen multitud de issues con preguntas sobre cómo instalar el módulo, incompatibildades, integraciones con otros módulos que deben ser atendidas y son excusas perfectas para revisar procesos y mejorar la documentación.
Mejoras (feature requests/tasks)
Existen muchas issues con interesantes sugerencias de mejora que deberían ser estudiadas y posiblemente introducidas en el módulo (ej. integración con el módulo scheduler, actualización de OAuth en la versión de Drupal 6, capacidad de importar "mentions" de una cuenta). El proceso a seguir con estas es el mismo que con los bugs.
Tests
Sólo un 20% del módulo está validado por tests (ésta es una apreciación humana). Ésto hace que corregir bugs suponga revisar a mano que las correcciones no afectan negativamente a otras áreas del módulo. Durante los próximos días se crearan issues para implementar tests funcionales que simulen:
- Añadir una cuenta de Twitter a un usuario con OAuth.
- Iniciar sesión con una cuenta de Twitter.
- Publicar un post a una cuenta de Twitter al crear o editar un contenido.
- Publicar un post a una cuenta de Twitter al producirse un evento del módulo Trigger.
- Publicar un post a una cuenta de Twitter al producirse un evento del módulo Rules.
Tras la discusión en los comentarios, se simularán las llamadas a la API de Twitter mediante una Mock class.
Issue principal con enlaces específicos a cada área del módulo que debe implementar tests.
Documentación
Las siguientes áreas de documentación deben ser revisadas, reestructuradas y mejoradas:
- Los README.txt de la versión de Drupal 6 y Drupal 7.
- Cada función del módulo debería estar documentada siguiendo el formato de Doxygen.
- La propia documentación en Drupal.org.
- Existen multitud de blogs que explican tareas del módulo que se podrían enlazar, reutilizar e incluso actualizar mediante una sugerencia en un comentario. Se podría hacer un listado de estas páginas a modo de guía.
- Crear un listado de módulos relacionados con el estado del mismo para poder contactar con los mantenedores posteriormente.
Comments
Centrémonos.
@juampy,
En primer lugar enhorabuena por el éxito que está teniendo la iniciativa y gracias por plantearla. Yo personalmente tenía ganas de ver algo parecido a esto en marcha.
También es de agradecer toda la documentación que estás generando. Muy bien estructurada y sintética.
Con respecto a la división de tareas, creo que habría que darle prioridad a los tests y a los bugs, en ese orden. Las nuevas mejoras creo que pueden confundir y requerir más tiempo, por lo que puede que precisen más tiempo del que se ha determinado para el evento y la gente no vea el ciclo total de una issue, que es lo importante. Aunque somos bastante gente, yo dejaría estas para los que quieran colaborar a medio-largo plazo. Ahora, que esto es una "doocracy" y cada cual...
Con respecto a los tests yo me declino por usar una cuenta de pruebas, aunque si el mock ya está disponible puede que nos ahorre tiempo y que los tests se ejecuten más rápido. Si el objeto mock no está disponible habrá que implementarlo y eso tambien es tiempo y gente esperando a que esté disponible. Yo me apunto a los tests con @carlescliment.
Un saludo,
Alessandro Mascherpa.
Respecto a si usamos llamadas
Respecto a si usamos llamadas reales a twitter o mock objects, me decanto por los mocks sin ninguna duda.
Los tests sobre un módulo deberían cubrir el código del módulo, pero nunca depender de sistemas externos. Es decir, cualquier test de Drupal debería poder ejecutarse en una máquina con el cable de red desconectado.
Imaginad que hacemos peticiones reales a twitter. Imaginad que 100 empresas tienen servidores de integración contínua ejecutando los test varias veces al día. ¿Qué ocurrirá si en Twitter deciden borrar la cuenta de testing? ¿Y si se les cae el servicio porque les cae un rayo en el edificio de los servidores? O si hay problemas temporales en mi conexión a Internet...
El problema aquí es que haciendo llamadas reales estamos probando muchas más cosas que el módulo.
El problema con los mock objects es que necesitan de un buen diseño en la programación. Por eso muchas veces, cuando intentas cubrir con tests un módulo, es necesario empezar con un poco de refactoring.
Por ejemplo, si tenemos una función para lanzar un tweet parecida a esta:
function twitter_send_tweet($tweet, $twitter_account) {// do stuff
$api = new twitterAPI();
// do whatever with the api object and update the user status in Drupal.
}
No vamos a poder testear la función, dado que el objeto a mockear se está instanciando dentro.
Una solución es añadir el objeto twitterAPI como parámetro a la función, lo que obliga a modificar las funciones invocantes para que sean ellas las que instancien y proporcionen el objeto a la función.
Vamos, que para un módulo como este es posible que si queremos testearlo bien tengamos que remover un poco sus tripas.
Estoy de acuerdo
Estoy de acuerdo con la explicación. No he podido encontrar ningún módulo contribuído que tenga tests que traten con librerías externas y que utilicen clases Mock para simular la comunicación con ellas, con lo que habrá que investigar estrategias.
Por lo que he visto hasta ahora, las llamadas a la API de Twitter se realizan en Twitter->request. De momento bastaría con detectar que estamos en un test para que, en vez de llamar a la API de Twitter, pase la información a una Mock class que simule la respuesta correspondiente.
De aquí al sábado intentaré actualizar los tests para que no hagan llamadas reales. Supongo que tras esto tendré sugerencias más consistentes.
De todos modos, independientemente del método que sigamos, los objetivos de añadir tests siguen siendo los mismos, con lo que paso a crear la lista de tareas de las áreas que requieren un test. Añadiré el listado a la sección Tests de ésta página.
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
Difícil
Desde luego esto del mocking es bastante complicado en Drupal y no parece que nadie haya aportado una solución definitiva.
Lo ideal es que el código de los módulos fuera agnóstico a los tests que los cubren. Es decir, no debería programar un Mock Object en el módulo y "fork"-ear el código según esté testeando o no porque
a) estamos generando ruído en el código.
b) necesitaremos crear los mocks desde el módulo, obligando por tanto a mantener esta parte del testing en el módulo y no en el test.
c) para detectar si estamos testeando o no, tendremos que usar mecanismos de un framework de testing en concreto (en este caso SimpleTest). Pero deberíamos poder cambiar de framework de testing cualquier día sin tener que modificar el código.
Algunos han sugerido utilizar runkit, que permitiría hacer mocks de objetos sin "ensuciar" el código, pero nunca se ha llegado a hacer en módulos de Drupal (que yo sepa).
Si no encontramos alguna solución sencilla, preferiría limitar los tests a mezclar código de testing en el módulo. Si no podemos utilizar la clase DrupalWebTestCase con peticiones completas siempre podemos testear unitariamente las funciones que realizan llamadas a Twitter.
A ver qué opináis, un saludo.
Valdría la pena evaluar runkit
OK. He añadido una issue al índice de tareas de testing para investigar sobre esto con la información que he podido encontrar.
http://drupal.org/node/1342664
Saludos
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
La dirección de la api de
La dirección de la api de twitter debería ser configurable para que llamase o a la api de twitter o a la de test (incluso a la de identi.ca que creo que implementa un clon de la api de twitter) y que esración se pueda pasar a la hora de hacer testa configu
Si bien runkit tiene buena pinta...
Si bien runkit tiene buena pinta no se si es lo mas adecuado teniendo en cuanta los requisitos y proceso de instalación requerida (ya que no forma parte del paquete standar de php): http://www.php.net/manual/en/runkit.installation.php
He encontrado este enlace que propone un metodo super sencillo para hacer mocks a la Drupal way y de manera iterna: http://groups.drupal.org/node/22332
Esto junto con el tener la variable con la url del servicio en configuración como propone @rodrigoaguilera puede dar una solución sencilla y que nos de los resultados esperados, ya que:
- El mock va en un módulo a parte. De esta manera no se contamina el código ni del módulo ni de los tests del mismo.
- contamos con un servidor REST caserete e integrado que sustituye adecuadamente el servicio que nos ofrezca al API de twitter.
- En un módulo a parte se puede emular el servicio externo con tablas internas de datos.
- Si la url de ataque al servicio está por configuración como propone @rodrigoaguilera se puede cambiar la vuelo con el setup del test y luego deshacer el cambio cuando el test a acabado.
¿Que os parece?
Un saludo,
Alessandro Mascherpa.
Vale la pena evaluarlo
He creado una tarea para ello en la sección de investigación.
http://drupal.org/node/1342664
Parece bastante factible. Quizá haya que modificar la clase Twitter para poder cambiar la propiedad $host a nivel de clase para que cuando el módulo instancie la clase tenga ya el valor que queremos en $host.
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
Alessandro, coincido contigo
Alessandro, coincido contigo en que runkit es problemático.
Pero no alcanzo a entender la solución propuesta.
¿Para testear el módulo Twitter será necesario otro módulo? Es decir, ¿el módulo no debería testearse a sí mismo? ¿Dónde estará entonces el test sobre Twitter, en el twitter.test o en mock_module.test?
Ojo, que creo que la senda es buena, pero esto de necesitar un módulo extra me confunde.
No es necesario otro módulo
Lo que se necesitan son dos clases:
* Un singleton para solicitar la URL de conexión que tenga un método para poder modificarla en los tests.
* Otra para el MockWebService del ejemplo.
Sin duda que la idea es buena :-D
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
La idea del singleton me ha
La idea del singleton me ha encantado.
Enhorabuena a los dos!
Desplazando la conversación
Desplazando la conversación a: http://drupal.org/node/1343474
Creo que es más apropiado y dejamos este post libre para discutir otras tareas.
Un saludo,
Alessandro Mascherpa.
Issues para los tests añadidas
He añadido a la página, en la sección Tests, una referencia a una issue que agrupa las issues específicas de cada área que debería implementar tests.
Se trata de http://drupal.org/node/1342664.
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
pequeño asunto para la
pequeño asunto
para la colaboración madrid-valencia usaremos #drupal-es o un canal nuevo de IRC
yo voto por #drupal-es ya que los sabados no está muy concurrido y si aparece alguien se puede sumar
Crearé #DrupalConTribute
Crearé #DrupalConTribute, pero si vemos que #drupal-es está vacio, podemos utilizarlo también.i
Senior Developer at Lullabot
https://www.lullabot.com/who-we-are/juampy-nr
+1 a mantener los canales existentes
+1 a mantener los canales existentes
--
[develCuy](http://steemit.com/@develcuy) on steemit
Para Mañana en Madrid traerse
Para Mañana en Madrid traerse regletas y cojines para las posaderas delicadas.
Oskar