Estuve leyendo un post del blog de Airbnb sobre testing: http://nerds.airbnb.com/testing-at-airbnb/ y quiero resaltar algunos puntos que me parecieron importantes
First, we needed to take a lesson from the PR rollout and lead by example. This meant including tests with any PRs we submitted, whether it was new feature development, bug fixes, or refactors.
Me pareció algo muy interesante incluir casos de test en los pull requests, lo cual me lleva a pensar un poco en el nivel de granularidad de los casos de test. En los proyectos que trabajé, es común hacer clases de test que testean una clase. Todos sus métodos con todas sus funcionalidades. Terminamos teniendo clases kilométricas que luego es difícil saber cuando falla un test a qué se debe el fallo. ¿Será cuestión de tener clases de test que testeen una funcionalidad? Sin duda simplificaría y ayudaría a enfocar al desarrollador para escribir en el test qué es lo que está testeando y también permitiría a algún externo ejecutar ese caso de test y validar un pull request:
we needed a few critical components to be in place: a way to run individual tests quickly and reliably on a dev machine, a way to run the full suite quickly and painlessly in the cloud, and a way to make sure that every PR had a passing build before it was merged.
Revisar y probar:
Having a CI server building all commits across all branches was a huge first step, but to make this useful we needed to surface the outcome of these builds. This is where GitHub’s commit status API comes in. Every time our CI server begins a build, it pings GitHub’s commit status endpoint, and every time it completes a build it hits the endpoint again with the outcome. Now every open PR includes a yellow/red/green indicator for the branch in question, with a direct link to the build status page on our CI server. In practice this means more transparency, faster feedback cycles, and a guarantee that every branch merged into master has a passing test suite. This integration has been a huge help in keeping our master branch green, and has thus greatly reduced our deploy times (since engineers aren’t waiting on build failures to be resolved in master).