1. TDD: Cómo escribir código testeable.

2. ¿Hacer tests es bueno?

3. ¿Por qué no los hacemos?

4. Razones Válidas ¡No se! Código antiguo UI No hacer pruebas Inválidas El diseño es malo De eso se encarga QA No coge los bugs Demasiadas interfaces Es lento Aburido…. Es dificil de cambiar

5. Hacer tests es una habilidad

6. Entonces… ¿Cómo se escribe código difícil de probar?

7. ¿Por qué? Construcción de objetos Trabajo en el constructor Estados globales Violaciones de la Ley de Deméter

8. Localización del “new” Estímulo API de Pruebas Clase bajo prueba Verificaciones

9. Localización del “new” Otra clase Estímulo Otra clase API de Pruebas Clase bajo prueba Verificaciones Otra clase Instanciado dentro de la clase Pasado por referencias Estados globales

10. Localización del “new” Otra clase Otra clase Otra clase Otra clase Estímulo Otra clase API de Pruebas Clase bajo prueba Otra clase Verificaciones Otra clase

11. Localización del “new” Otra clase Otra clase Otra clase Otra clase Estímulo Otra clase API de Pruebas Clase bajo prueba Costura Otra clase Verificaciones Otra clase

12. Localización del “new” Clase Falsa Estímulo Clase Falsa API de Pruebas Clase bajo prueba Costura Verificaciones Clase Falsa

13. Localización del “new” Lógica de Negocio Construcción del Grafo de Objetos y Búsqueda

14. Localización del “new” Lógica de Negocio Construcción del Grafo de Objetos y Búsqueda

15. Localización del “new” Clase Falsa Estímulo Clase Falsa API de Pruebas Clase bajo prueba Verificaciones Clase Falsa Instanciado dentro de la clase Pasado por referencias Estados globales

16. Ejemplo (House)

17. House classHouse { Kitchenkitchen = new Kitchen(); Bedroombedroom; publicHouse() { this.bedroom = new Bedroom(); } }

18. House Test classHouseTests { @Test publicvoidimpossibleTestOnIsolation() { // Can’treplaceanything!!! } }

19. Análisis Fácil de instanciar pero… No se puede remplazar nada. Puede ser costoso computacionalmente El diseño está acoplado. Cerrado para extensión.

20. House (Refactoizado) classHouse { Kitchenkitchen; Bedroombedroom; @Inject publicHouse(Kitchenkitchen, Bedroombr) { this.bedroom = br; this.kitchen = kitchen; } }

21. House Test (Refactorizado) classHouseTests { @Test publicvoideasierToTestOnIsolation() { DummyKitchendk = new DummyKitchen(); DummyBedroomdb = new DummyBedroom(); House h = new House(dk,db); // … } }

22. Ejemplo (Gardener)

23. Gardener class Garden { Gardenerjoe; public Garden(Gardenerjoe) { joe.setWorkHours(new TwelveHours()); joe.setBoots(new ExpensiveBoots()); this.joe = joe; } }

24. Análisis Mejor pero… No se pueden remplazar las botas o el horario. La prueba puede tardar (horario de 12h). Necesita el jardinero pero se encarga de configurarlo.

25. Gardener (Refactored) class Garden { Gardenerjoe; @Inject public Garden(Gardenerjoe) { this.joe = joe; } } classGardenerProvider { @Provides GardenergetGardener(ExpensiveBootsboots, TwelveHoursschedule) { Gardenerjoe = new Gardener(); joe.setWorkHours(schedule); joe.setBoots(boots); returnjoe; } }

26. ¿Por qué? Construcción de objetos Trabajo en el constructor Estados globales Violaciones de la Ley de Deméter

27. Costo de la construcción Para testear, primero hay que instanciar pero… El trabajo dentro del constructor no tiene “costuras” No se puede sobre escribir. La prueba tiene que saber navegar lo que haya dentro

28. Ejemplo (Super Car)

29. Super Car class Car { Engineengine; public Car(Filefile) { String m = readModelFromCfg(file); engine = new EngineFactory().create(m); } }

30. Super Car Test classCarTest { @Test publicvoidhardToSetupTest() { Filefile = new File(“custom.conf”); Car car = new Car(file); //Asserts... } }

31. Análisis Pasamos un File cuando lo que se necesita es un Engine. Toda prueba que necesite Car requiere eta parafernaria. Accede al sistema de ficheros Lento. No es una prueba unitaria realmente.

32. Super Car (Refactorizado) class Car { Engineengine; @Inject public Car(Engineengine) { this.engine = engine; } }

33. Super Car (Provider) classCarEngineProvider { @Provides EnginegetEngine(EngineFactoryfactory, @EngineModelStringmodel) { returnfactory.create(model); } }

34. Super Car Test (Refactorizado) classCarTest { @Test publicvoideasyToSetupTest() { Engineengine = new FakeEngine(); Car car = new Car(engine); //Asserts... } }

35. ¿Por qué? Construcción de objetos Trabajo en el constructor Estados globales Violaciones de la Ley de Deméter

36. Locura

37. Locura Definición: Repetir una misma acción una y otra vez y esperar obtener un resultado diferente. Albert Einstein

38. O mejor dicho… Estados Globales class X { public X() { } publicintdoSomething() { //… Something… } }

39. Estados Globales int a = new X().doSomething(); int b = new X().doSomething();

40. Estados Globales ¿ a == b ó a != b ?

41. Estados Globales X x1 = new X(); Y Q X Z

42. Estados Globales X x1 = new X(); X x2 = new X(); Y Q X Z Y Q X Z

43. Estados Globales X x1 = new X(); x1.doSomething(); A == B ó A != B X x2 = new X(); x2.doSomething(); Y Q X Z GS Y Q X Z

44. Consecuencias Múltiples ejecuciones Resultados inesperados Orden importa No se pueden ejecutar en paralelo Localización del estado desacotado.

45. Estados Globales Ocultos System.currentTime() new Date() Math.random()

46. Consecuencias La API miente: A cerca de lo que necesita Hace cosas que dan miedo detrás de la fachada

47. Ejemplo (CreditCard)

48. CreditCard @Test publicvoidcreditCardChargeTest() { CreditCardcc = new CreditCard(“1234567890”); cc.charge(200); }

49. CreditCard @Test publicvoidcreditCardChargeTest() { CreditCardcc = new CreditCard(“1234567890”); cc.charge(200); } java.lang.NullPointerException at talk2.CreditCard.charge(CreditCard.java:48)

50. CreditCard @Test publicvoidcreditCardChargeTest() { CreditCardProcessor.init(…); CreditCardcc = new CreditCard(“1234567890”); cc.charge(200); }

51. CreditCard @Test publicvoidcreditCardChargeTest() { CreditCardProcessor.init(…); CreditCardcc = new CreditCard(“1234567890”); cc.charge(200); } java.lang.NullPointerException at talk2.CreditCardProcessor.init(CreditCardProcessor.java:134)

52. CreditCard @Test publicvoidcreditCardChargeTest() { OfflineQueue.start(); CreditCardProcessor.init(…); CreditCardcc = new CreditCard(“1234567890”); cc.charge(200); }

53. CreditCard @Test publicvoidcreditCardChargeTest() { OfflineQueue.start(); CreditCardProcessor.init(…); CreditCardcc = new CreditCard(“1234567890”); cc.charge(200); } java.lang.NullPointerException at talk2.OffileQueue.start (OfflineQueue.java:203)

54. CreditCard @Test publicvoidcreditCardChargeTest() { Database.connect(…); OfflineQueue.start(); CreditCardProcessor.init(…); CreditCardcc = new CreditCard(“1234567890”); cc.charge(200); }

55. CreditCard ¿Se ve un patrón?

56. CreditCard Miente sobre sus dependencias. El orden de las inicializaciones no es explicito.

57. CreditCard ¿Qué podemos hacer?

58. CreditCard (Refactorizado) @Test publicvoidcreditCardChargeTest() { Databasedb = Database(“connectionStr”); OfflineQueuequeue = new OfflineQueue(db); CreditCardProcessorccProcessor = new CreditCardProcessor(queue); CreditCardcc = new CreditCard(“1234567890”, ccProcesor); cc.charge(200); }

59. CreditCard ¡Tenemos opciones!

60. CreditCard Pero… ¿Y si termino con 20 parámetros? Es porque los tenias… solo que…

62. Accounting 101 classAccountView { Useruser; publicAccountView() { user = RPCClient.getInstance().getUser(); } }

63. Análisis Uso de Estados Globales Incorpora las dependencias del “singleton” Miente a cerca de las dependencias.

64. Accounting 101 classAccountView { Useruser; publicAccountView(Useruser) { user = user; } }

65. ¿Por qué? Construcción de objetos Trabajo en el constructor Estados globales Violaciones de la Ley de Deméter

67. La ley de Deméter Cada unidad debería tener conocimiento limitado sobre otras unidades: solo unidades “relacionadas de cerca” a la unidad actual. Cada unidad debe de hablar solamente con sus amigos; No hablar con extraños. Habla solamente con tus amigos inmediatos.

68. ServiceLocator Aka. Context, aka. Registry… etc. Mejor que un singleton Al menos el problema está en un solo lugar. Es testeable… pero no muy bonito. Esconde las dependencias reales. Las dependencias hacen el código poco reusable.

69. ServiceLocator ClassHouse { //… publicHouse(Locatorlocator) { //… Qué tengo que mockear??? } }

70. House ClassHouse { //… Windowwindow; Doordoor; Roofroof; publicHouse(Locatorlocator) { this.window = locator.getWindow(); this.door = locator.getDoor(); this.roof = locator.getRoof(); } }

71. House (Refactorizado) classHouse { //… Windowwindow; Doordoor; Roofroof; publicHouse(Window w, Door d, Roof, r) { this.window = w; this.door = d; this.roof = r; } }

72. ServiceLocator ¿Qué otro problema tiene? Mezcla responsabilidades. Buscar y encontrar. Creación Se necesita tener una interface para testear Si dependes de ServiceLocator, dependes de todo lo demás.

73. Making a Mockery… classLoginPage { RPCClientclient; HttpRequestrequest; publicLoginPage(RPCClientclient, HttpRequestrequest) { this.client = client; this.request = request; } publicbooleanlogin() { String cookie = request.getCookie(); returnclient.getAuthenticator().authenticate(cookie); } }

74. Análisis Para testear se hace complicado Las dependencias no son las declaradas. Crear rpcclient, entrenarlo para devolver un authenticator, crear un authenticator… Etc.

75. Making a Mockery… classLoginPage { Authenticatorauthenticator; String cookie; publicLoginPage(Authenticatorauth, @Cookie String cookie) { this.cookie= cookie; this.authenticator = auth; } publicbooleanlogin() { returnauthenticator.authenticate(cookie); } }

76. Making a Mockery Cosas a tener en cuenta. Tiempo de vida de los objetos que se pasan. Ej. Cookie puede ser distinto para cada vez