Hay ocasiones en las que se implementa un método que definen una serie de operaciones. Si tenemos otro método que implementa las misma serie de operaciones pero con algunas partes variables entonces se puede hacer un refactorización en la que se crea una clase padre con el método con las partes comunes y las subclases implementen las partes variables.
En el ejemplo de xUnit se puede apreciar la secuencia de operaciones de la clase padre «TestCase».
Las clases hijas son las que implementan los distintos métodos.
La pregunta que surge es cuándo se debería escribir una implementación por defecto. En los casos de los métodos «setUp()», «tearDown()» no tienen operaciones por defecto aunque son necesarios para el funcionamiento de la secuencia por lo que habría que implementarlos.
Si la secuencia de operaciones necesita una operación la cual necesita una implementación específica entonces se debería advertir declarando el método abstracto o implementando el método y lanzando una excepción.
El software nos rodea. Está por todas partes, incluso ahora mismo, en esta habitación, puedes verla si miras por la ventana o al encender la televisión. Puedes sentirlo, cuando vas a trabajar, cuando vas al supermercado, cuando pagas tus impuestos. Es el mundo tecnológico que se ha puesto ante tus ojos para ocultarte la verdad: que eres un esclavo del software. Sobre todo del mal software.
miércoles, 4 de julio de 2018
Capítulo 33: Design Pattern - Template Method - TDD By Example
Etiquetas:
Kent Beck,
tdd,
TDD By Example,
Test-Driven Development
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario