Ahora que se ha pasado un poco la tormenda de TDD is dead y cada uno ha podido buscar las armas y posicionarse de bando que más le convenía creo que es el momento de que podamos hablar de testing en el mundo real.
Antes de explicar cual es mi aproximación para hacer testing automático está bien que explique qué significa para mi:
Odio el testing, testear es un mal necesario, si pudiese no testearía, cuando hago algo personal no testeo, ni se me pasa por la cabeza joderme la vida pensando en testear cuando estoy disfrutando programando algo que quiero ver cuanto antes. Odio todo lo relacionado con el testing y sobretodo odio que la gente centre toda la atención en el testing, como si el testing por si solo sirviese de algo.
Pero el testing es necesario. Es como ir a comer con tus suegros (*), sabes que si no lo haces va a ser mucho peor. Puede que en algún proyecto corto merezca la pena no hacerlo, pero en general habría que estar muy tocado para no hacerlo y tener una suite de test que te permita estar un poco más seguro, sobretodo a largo plazo.
Dicho esto, mi política para hacer tests es:
Si puedo hago solo test de integración: intento hacer mocks de los extremos y testeo la máxima parte del stack posible. Por ejemplo, si tengo que testear un diálogo (html + javascript) creo el diálogo con los modelos adecuados y lanzo los eventos que lanzaría el usuario y hago checks del UI y de lo que debería tener el servidor/modelo. Como anecdota, el backend de la app que estuvo un día en portada de google tenía 25 tests que cubrían casi todos los casos. Es posible que estés testeando la misma cosa varias veces, se puede vivir con ello sin problema.
Casi-nunca hago el test antes. Sinceramente, a mi hacer el test antes no me dice nada del diseño, como mucho me dice si se me ha olvidado algún parámetro, pero de ahí a que la arquitectura emerja va un paso. Cuando programo algo ya tengo en la cabeza lo que debe hacer a alto nivel, los detalles de implementación no son el diseño amigos (aunque nos lo vendan así).
Sólo hago el test antes cuando voy a resolver un bug. Ya sabéis, RED -> FIX -> GREEN. Si puedo añadir un assert más a un test que ya existe lo hago, aunque no todos los bugs permiten hacer esto.
Solo hago unit test (que muchas veces no lo son) para cosas concretas en las que quiero testear edge-cases de cosas concretas o partes muy críticas.
No hago TDD. Lo intenté en su día (hace unos 8 años) y sería por mi poca experiencia, que no le puse mucho empeño, pero no lo vi claro o lo mismo es que ya odiaba el testing.
Intento usar los menos fuegos artificiales posibles para hacer los assert, esto es, todo el syntactic sugar que te dan frameworks como jasmine está muy bien, pero casi siempre sobra. Con un assert el 90% de las veces es mucho más que suficiente. Esto lo aprendes tras usarlos a muerte, actualizar la versión de jasmine (o tu sistema de testing favorito) y ver que lo han cambiado porque era mucho más guay.
A veces hago tests que varían en función de la máquina o que dependen de servicios externos. A veces merece la pena aunque terminan por machacar el sistema de integración continua.
(*) pongo el ejemplo de los suegros pero puedes poner ahí otro tópico cualquier, esta afirmación no representa de ninguna forma mi experiencia personal y espero que quieras muchísimo a tus suegros. Si eres suegro espero que no dejes de querer a tu yerno/nuera.
I’ve been working with apps that use GPS since 8 years. I’m not an expert on that mather, I’m far to know all the stuff related to high precision GPS, post processing, RTK, how a GPS works internally and so on. In any case there are a bunch of tips from the app programmer point of view you may find useful.
First of all, if you are going to create an app that needs to measure things forget to use any kind of internal GPS. I don’t recommend it since the error is really big even with clear sky view (no obstacles). Those GPS are very good in saving battery, adquiring singal pretty fast but that’s all.
So the tips, most of them from the development of agroguia, a GPS guidance system for farmers and flatout, a timing app for race cars.
Save all the data so you can reproduce it in a emulator with exactly the same timing. So save the timestamp GPS provides and, very recommended, the time the GPS gives you the information. I usually save the tick when the info was processed so the steps can be reproduced exactly in the same way they happened (this will save you hours of debugging)
GPS position information comes from the real world. And in the real world there is noise so forget about the good data you usually get from a JSON API. You need to know basic stuff about signal processing: filters, hysteresis, extrapolation, interpolation and so on. And please, please, use relative coordinates and time to interpolate.
For example, it’s pretty common to get 25 meters jumps and it’s clear that a bike can’t do 25 meters/s (in normal conditions) so if you are coding a strava like app, take that into account. Use domain information to fix those errors. You even can improve that more using some statistics.
Store your data properly: Use a standard format, SHP, GeoJSON, CSV, whatever but it should be easily readable by GIS apps, you don’t want to create your own applications for that. I use CartoDB to analize the data and before CartoDB I had my own tools (that’s why I know how horrible is to do it on your own) and google earth. Don’t forget to store speed and course from the GPS, you could calculate them from position and time but gps devices uses doppler to calculate them so it’s an independent variable (which is pretty useful for extrapolation)
Use the maximun precision you can but don’t store more precision than the GPS devices give you. Normally with a ieee754 float is enough, for precisions below 20 centimeters you need to go with a double (I’m always talking about WGS84 lat/lng).
Use the right projection. If you are going to measure things, use projections that don’t include distorsion in the zones your app is going to be used. You need to remember those lessons (looked useless at that time eh?) about floating point errors and you may need to use derivates to know the maximum error (read this). I use a variation of UTM where the center is in the first position I get from the GPS.
Be able to tag your tests. The good thing about programming GPS apps is that you can go out and see the sun from time to time but remember, once you get the data tag it to know exactly what you did in the field. It’s pretty common to not be able to remember what happened. I use a gopro cam these days to record what I do, for example in this case I use it to link gps traces with real world events and measure errors.
Manage all the GPS states. A GPS can lost the signal so give information to the user about that and log it somewhere so you can reproduce it.
Try to use GPS with more than 1hz update rate. There are lot of cheap GPS units with 4hz which is a big step in terms of user experience.
Dig into GPS documentation, they have some presets to work in different conditions (plane, pedestrian, static…) that change the behavior a lot. Learn about the information they give you. For example, when we created agroguía version for planes we needed to change lot of GPS params in order to work properly.
Hope you like it, if you want to know more in deep information ping me @javisantana
Ayer, un amigo que ha sido compañero de trabajo en ya dos empresas y de los que tiene la cabeza encima de los hombros, me comentaba mientras nos calzábamos unos buenos copazos que poco menos que se habían reído de él cuanto estaba explicando su solución técnica para gestionar cuentas de millones de usuarios porque usaba eval
Hace no demasiado, en la SpainJS (una conferencia de javascript), un chaval de Spotify decía, con cierto reparo, que usaban iframes. En la charla además explicó cómo se comunicaban y qué diferentes aproximaciones habían usado, lo que hizo que fuese, de largo, la mejor charla de la conferencia. Lo que se me quedó grabado es que casi pedía perdón por usar iframes. Se conoce que alguien en alguna parte dijo que los iframes no eran una solución elegante, que era cutre.
Estos son dos ejemplos, pero veo mucho más todos los días, gente aclamando que siempre debes hacer TDD, que lo más importante es que el código quede perfecto, discutiendo si tal o cual tecnología es una bazofia. A menudo se nos olvida que hay un factor que todos tenemos muy limitado, y es el tiempo. Y para hacer cosas en tiempo hay que hacer algunas cosas cutres, cosas mal vistas, dejar lo que ahora todos llaman deuda técnica que no deja de ser lo que toda la vida se ha llamado ingeniería, o dicho de otro modo, saber qué puedes puentear y qué debes hacer lo mejor que puedes. No se puede, bajo ningún concepto, hacer siempre lo mejor que puedes en un proyecto, porque estarías tirando tu tiempo.
Cada vez que haces algo cutre, es decir, cada vez que tomas una decisión técnica que no es la perfecta, sino la ideal para eso, alégrate, acabas de ganar un poco de tiempo de tu vida. Pero claro, para saber en qué debes apretar los machos y dónde dejar esa deuda normalmente tienes que tener una perspectiva que los programadores no solemos tener y lo tapamos con basura técnica. Y no se te olvide anotar que esas cosas las has hecho así por si viene algún espabilado después criticando lo que hiciste en su día (no te preocupes, puedes poner comentarios en el código, son bienvenidos).
No recuerdo cuando ni donde le escuché al mítico Javier Arévalo algo así como:
código cerrado >>>> código acabado
Cuando tienes un producto y vas a meter una nueva feature hay una distancia abismal entre tenerla acabada y en producción (cerrada). Vamos ser claros, lo de “say NO” es muy bonito cuando escribes libros pero la realidad es que el software requiere cosas nuevas de vez en cuando (de hecho muy de vez en cuando)
Digamos que tenemos una feature acabada, todo funcionando en desarrollo y podemos usarla sin problemas en un entorno “controlado” (staging o como lo llames). Pero eso es la punta del iceberg del trabajo. Una feature es como un hijo, no vale con “poner la semillita en mamá”, hay que llevarla por el camino correcto y dejarla ir cuando toque.
Estas son algunas de las cosas en las que deberíamos pensar (que no hacemos porque entraríamos en depresión):
Si eres desarrollador de sofware o estás cerca de ellos te sonará lo de “no puedo reproducir este problema” o el famoso “funciona en mi máquina”. Normalmente cuando vas a resolver un bug el flujo es el siguiente:
1) alquien lo reporta, normalmente con una descripción pobre y mal especificado
2) lo reproduces
3) lo fixeas
4) el que lo reportó o un QA prueba que efectivamente eso está cerrado
Dejando a un lado el tema del report de bugs, que muy poca gente sabe hacer bien (incluídos desarrolladores), hay muchas ocasiones donde el paso 2 es imposible o difícil: las condiciones de partida suelen ser diferentes, el entorno, etc. Cuando esto pasa te pasas horas tratando de ponerte en el pellejo del que lo encontró dando a menudo palos de ciego a ver si suena la flauta.
En estas últimas dos semanas por desgracia he tenido que solucionar bastantes bugs (culpa mía todos y cada uno de ellos) y uno de ellos surgió justo antes de tener que ir a coger el tren. Era más o menos urgente así y no podía utilizar el portátil para reproducirlo y arreglarlo, así que intenté resolverlo de memoria.
Tracear el programa sin tener claro como reproducir el problema viene a ser como hacer una raiz cuadrada de memoria. Lo mejor no es que ejercitas la memoria si no que mientras vas analizando cada caso concreto y como podría afectar a tu código encuentras posibles fallos, mejoras y WTF que hiciste cuando lo programaste.
Llevo haciendolo cosa de dos semanas y es especialmente interesante sobretodo cuando tratas de reproducir bugs en código ajeno.
Y es que al final la cabeza va mucho más rápido que la vista y los dedos buscando entre el código usando el editor. Antes de ponerse a mirar como un loco el código analiza 5 minutos sin tocar el ordenador qué puede estar pasando.