Un sí rotundo con TDD (y con algunas excepciones)
Está bien, es controversial, pero yo diría que a cualquier persona que responda "no" a esta pregunta le falta un concepto fundamental de TDD.
Para mí, la respuesta es un rotundo sí si sigues TDD. Si no lo eres, entonces no es una respuesta plausible.
El DDD en TDD
A menudo se cita que TDD tiene sus principales beneficios.
-
Defensa
- Asegurarse de que el código puede cambiar pero no es su comportamiento .
- Esto permite la práctica tan importante de refactorización .
- Ganaste este TDD o no.
-
Diseño
- Usted especifica qué debe hacer algo, cómo debe comportarse antes de implementarlo .
- Esto suele significar más decisiones de implementación .
-
Documentación
- El conjunto de pruebas debe servir como documentación de especificación (requisitos).
- El uso de pruebas para tal fin significa que la documentación y la implementación siempre se encuentran en un estado coherente; un cambio en uno significa un cambio en otro. Compare con los requisitos de mantenimiento y el diseño en un documento de Word separado.
Separar la responsabilidad de la implementación
Como programadores, es terriblemente tentador pensar que los atributos son algo de importancia y que los captadores y definidores son una especie de sobrecarga.
Pero los atributos son un detalle de implementación, mientras que los definidores y captadores son la interfaz contractual que realmente hace que los programas funcionen.
Es mucho más importante deletrear que un objeto debe:
Permitir a sus clientes cambiar su estado
y
Permitir a sus clientes consultar su estado
luego, cómo se almacena realmente este estado (para el cual un atributo es el más común, pero no la única forma).
Una prueba como
(The Painter class) should store the provided colour
es importante para la documentación de TDD.
El hecho de que la implementación final sea trivial (atributo) y no conlleve ningún beneficio de defensa debe ser desconocido para usted cuando escribe la prueba.
La falta de ingeniería de ida y vuelta ...
Uno de los problemas clave en el mundo del desarrollo de sistemas es la falta de round-trip engineering 1 : el proceso de desarrollo de un sistema se fragmenta en subprocesos inconexos. los artefactos de los cuales (documentación, código) son a menudo inconsistentes.
1 Brodie, Michael L. "John Mylopoulos: cosiendo semillas del modelado conceptual". Modelado Conceptual: Fundamentos y Aplicaciones. Springer Berlin Heidelberg, 2009. 1-9.
... y cómo lo resuelve TDD
Es la parte documentación de TDD la que garantiza que las especificaciones del sistema y su código sean siempre coherentes.
Diseña primero, implementa más tarde
En TDD, primero escribimos la prueba de aceptación fallida, luego escribimos el código que los dejó pasar.
Dentro de la BDD de nivel superior, escribimos los escenarios primero, luego los hacemos pasar.
¿Por qué debería excluir setters y getter?
En teoría, es perfectamente posible dentro de TDD que una persona escriba la prueba y otra que implemente el código que la haga pasar.
Entonces pregúntate:
En caso de que la persona que escribe las pruebas para una clase mencione a captadores y colocadores.
Dado que los captadores y definidores son una interfaz pública para una clase, la respuesta es obviamente sí , o no habrá forma de establecer o consultar el estado de un objeto.
Obviamente, si escribes el código primero, la respuesta puede no ser tan clara.
Excepciones
Hay algunas excepciones obvias a esta regla: funciones que son detalles claros de la implementación y que claramente no forman parte del diseño del sistema.
Por ejemplo, un método local 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
O la función privada square() aquí:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
O cualquier otra función que no sea parte de una interfaz public que necesite ortografía en el diseño del componente del sistema.