IIC3745-2020-2/syllabus

Combinacion de Criterios de Coverage

Closed this issue · 1 comments

Quería saber como sería más correcto abordar el siguiente caso:
Estoy haciendo una librería o api, y quiero asegurar algun nivel de coverage, para lo cual elijo algun criterio A que no es tan exigente y lo uso para testear la el funcionamiento general. Pero por otro lado, tengo un par de funciones críticas para las cuales aplico el criterio B para asegurar una mejor calidad.
Es una "buena práctica" hacer esto? Y cual % de coverage (de A o B) debería publicar que tiene el código?

En mi opinión me parece un buen enfoque para ser más exigente con ciertas partes críticas del código solamente, y así no invertir en tests costosos para todo el código. Más que una "buena práctica" yo diría que es una visión pragmática sobre el desarrollo de software: se cuenta con recursos limitados para diseñar pruebas, por lo que estas se enfocarán en las funciones más críticas, aunque también se invertirá algo en el resto del código. Esta idea está relacionada con un diagrama que vimos en clases sobre el costo de realizar pruebas vs su beneficio.

Sobre el porcentaje de cobertura a publicar diría que esto no es relevante. Por ejemplo, si ves una librería que tiene 60% y un tiempo después tiene 65%: ¿podrías concluir algo sobre la calidad de la librería? ¿Y si tuviera 100%? Los criterios de cobertura son una ayuda al momento de diseñar pruebas y verificar qué partes del código están siendo probadas, pero el número por sí sólo no es útil. Quizás ver una librería con un alto porcentaje de cobertura genera más confianza sobre los mantenedores, pero si los tests son triviales este porcentaje no refleja nada. En este este artículo de Martin Fowler puedes encontrar más ideas sobre este tema.