TDD: ¿Qué métodos expones para las pruebas unitarias?
Hay un aspecto de TDD que nunca entendí completamente.
Supongamos que alguien le pide que implemente un objeto Stack simple. Si ha realizado su diseño correctamente, llegará a una API muy mínima y limpia. Suponer:push()
, pop()
yisEmpty()
. Cualquier cosa más que eso está sobrepasando la demanda y permitiendo al usuario demasiado espacio para meterse con su código.
Así que ahora supongamos que desea probar unitariamente su código. ¿Cómo haces esto si todos tus métodos públicos son solo los tres que se muestran arriba? Esos métodos llevarán sus pruebas solo hasta ahora.
Por lo tanto, agrega métodos privados, que no lo ayudan en absoluto, ya que no son visibles para el caso de prueba de su unidad. O haces públicos esos métodos y ahí está tu API minimalista en la que trabajaste tan duro. Ahora el usuario se va a meter con su Pila y los errores seguramente vendrán.
¿Cómo manejas este dilema de abrir métodos públicos para pruebas versus una API limpia y simple?
Editar: solo para apuntar en la dirección correcta, sería bueno obtener punteros técnicos (como "usar este truco para exponer métodos privados", etc.) pero estoy mucho más interesado en respuestas más genéricas sobre cuál de los dos los conceptos son más importantes y cómo aborda este tema.