Llega un momento en que algunos de nuestros juegos de prueba empiezan a tener muchas expectations y se empieza a complicar la implementación de nuevos tests o el mantenimiento de los existentes.
Una de las consecuencias de aplicar TDD es que cuánto mayor sea la complejidad del test, mayor será la complejidad de nuestro código, y por lo tanto, de su mantenimiento. Así que si empezamos a tener tests con demasiadas expectations, es buen momento para plantearse el refactoring de alguna de las clases, para simplificar o dividir su funcionalidad.
Si aún así seguimos mantiendo unas expectations muy largas, y que además se comparten entre varios tests, es muy recomendable agruparlas. Gracias a la implementación de jMock, podemos declarar varios bloques de expectations en un mismo test, de tal modo que la prueba deberá cumplir las condiciones de todos sus bloques:
Gracias a esta característica de jMock, podremos refactorizar y extraer el código común en varios métodos private, dentro de nuestra clase de test. Cada uno de estos métodos contendrá uno (o varios) de los bloques de expectations compartidas. Por ejemplo:
Este tipo de refactor para agrupar código común nos permitirá reducir bastante la longitud de nuestras clases de test, permitiendo que nos centremos en lo realmente importante: cuál es la entrada esperada, y cuál debe ser la salida. Sin duda, resulta especialmente útil cuando nuestra test suite está repleta de métodos findX() o updateY(), cuyo resultado queremos que sea el mismo en varias de las pruebas.
Una de las consecuencias de aplicar TDD es que cuánto mayor sea la complejidad del test, mayor será la complejidad de nuestro código, y por lo tanto, de su mantenimiento. Así que si empezamos a tener tests con demasiadas expectations, es buen momento para plantearse el refactoring de alguna de las clases, para simplificar o dividir su funcionalidad.
Si aún así seguimos mantiendo unas expectations muy largas, y que además se comparten entre varios tests, es muy recomendable agruparlas. Gracias a la implementación de jMock, podemos declarar varios bloques de expectations en un mismo test, de tal modo que la prueba deberá cumplir las condiciones de todos sus bloques:
@Test public void testFindHouseShouldReturnOneHouse() throws Exception { mockery.checking(new Expectations() { { // Expectations #1 } }); mockery.checking(new Expectations() { { // Expectations #2 } }); // ... code of the test ... }
Gracias a esta característica de jMock, podremos refactorizar y extraer el código común en varios métodos private, dentro de nuestra clase de test. Cada uno de estos métodos contendrá uno (o varios) de los bloques de expectations compartidas. Por ejemplo:
@Test public void testFindHousesShouldReturnHousesThatMatchColor() throws Exception { declareCommonExpectations(); // Expectations comunes mockery.checking(new Expectations() { { // Expectations of this test } }); // ... code of the test ... } @Test public void testFindHousesShouldReturnHousesThatMatchLocation() throws Exception { declareCommonExpectations(); // Expectations comunes mockery.checking(new Expectations() { { // Expectations of this test } }); // ... code of the test ... } [...] private void declareCommonExpectations() throws Exception { mockery.checking(new Expectations() { { // Este bloque contiene todas las expectations // comunes que compartirán ambos tests. } }); }
Este tipo de refactor para agrupar código común nos permitirá reducir bastante la longitud de nuestras clases de test, permitiendo que nos centremos en lo realmente importante: cuál es la entrada esperada, y cuál debe ser la salida. Sin duda, resulta especialmente útil cuando nuestra test suite está repleta de métodos findX() o updateY(), cuyo resultado queremos que sea el mismo en varias de las pruebas.
Comentarios
Publicar un comentario