TDD: ¿Cómo escribir código testeable?
Descargar como PPTX, PDF1 recomendación855 vistas
Este documento discute cómo escribir código que sea fácil de probar mediante pruebas unitarias. Explica que el código no testable suele involucrar estados globales, dependencias ocultas y trabajo en los constructores. Luego, presenta varios ejemplos de cómo refactorizar el código para eliminar estas características, inyectando dependencias y extrayendo lógica del constructor, lo que hace que el código sea más fácil de probar y menos acoplado.
TDD: ¿Cómo escribir código testeable?
- 1. TDD: Cómo escribir código testeable.
- 2. ¿Hacer tests es bueno?
- 3. ¿Por qué no los hacemos?
- 4. RazonesVálidas¡No se!Código antiguoUINo hacer pruebasInválidasEl diseño es maloDe eso se encarga QANo coge los bugsDemasiadas interfacesEs lentoAburido….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ímuloAPI de PruebasClase bajo pruebaVerificaciones
- 9. Localización del “new”Otra claseEstímuloOtra claseAPI de PruebasClase bajo pruebaVerificacionesOtra claseInstanciado dentro de la clasePasado por referenciasEstados globales
- 10. Localización del “new”Otra claseOtra claseOtra claseOtra claseEstímuloOtra claseAPI de PruebasClase bajo pruebaOtra claseVerificacionesOtra clase
- 11. Localización del “new”Otra claseOtra claseOtra claseOtra claseEstímuloOtra claseAPI de PruebasClase bajo pruebaCosturaOtra claseVerificacionesOtra clase
- 12. Localización del “new”Clase FalsaEstímuloClase FalsaAPI de PruebasClase bajo pruebaCosturaVerificacionesClase Falsa
- 13. Localización del “new”Lógica de NegocioConstrucción del Grafo de Objetos y Búsqueda
- 14. Localización del “new”Lógica de NegocioConstrucción del Grafo de Objetos y Búsqueda
- 15. Localización del “new”Clase FalsaEstímuloClase FalsaAPI de PruebasClase bajo pruebaVerificacionesClase FalsaInstanciado dentro de la clasePasado por referenciasEstados globales
- 16. Ejemplo (House)
- 17. HouseclassHouse {Kitchenkitchen = new Kitchen();Bedroombedroom;publicHouse() {this.bedroom = new Bedroom(); }}
- 18. House TestclassHouseTests { @TestpublicvoidimpossibleTestOnIsolation() { // 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;@InjectpublicHouse(Kitchenkitchen, Bedroombr) {this.bedroom = br;this.kitchen = kitchen;}}
- 21. House Test (Refactorizado)classHouseTests { @TestpublicvoideasierToTestOnIsolation() {DummyKitchendk = new DummyKitchen();DummyBedroomdb = new DummyBedroom();House h = new House(dk,db); // …}}
- 23. Gardenerclass 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; @Injectpublic Garden(Gardenerjoe) { this.joe = joe; }}classGardenerProvider { @ProvidesGardenergetGardener(ExpensiveBootsboots, TwelveHoursschedule) {Gardenerjoe = new Gardener();joe.setWorkHours(schedule);joe.setBoots(boots);returnjoe; }}
- 26. ¿Por qué?Construcción de objetosTrabajo 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
- 29. Super Carclass Car {Engineengine;public Car(Filefile) {String m = readModelFromCfg(file);engine = new EngineFactory().create(m);}}
- 30. Super Car TestclassCarTest {@TestpublicvoidhardToSetupTest() {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;@Injectpublic Car(Engineengine) {this.engine = engine;}}
- 33. Super Car (Provider)classCarEngineProvider {@ProvidesEnginegetEngine(EngineFactoryfactory, @EngineModelStringmodel) {returnfactory.create(model);}}
- 34. Super Car Test (Refactorizado)classCarTest {@TestpublicvoideasyToSetupTest() {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. LocuraDefinición:Repetir una misma acción una y otra vez y esperar obtener un resultado diferente.Albert Einstein
- 38. O mejor dicho… Estados Globalesclass X {public X() {}publicintdoSomething() { //… Something…}}
- 39. Estados Globalesint a = new X().doSomething();int b = new X().doSomething();
- 40. Estados Globales¿ a == b ó a != b ?
- 41. Estados GlobalesX x1 = new X();YQXZ
- 42. Estados GlobalesX x1 = new X();X x2 = new X();YQXZYQXZ
- 43. Estados GlobalesX x1 = new X();x1.doSomething();A == B ó A != BX x2 = new X();x2.doSomething();YQXZGSYQXZ
- 44. Consecuencias Múltiples ejecuciones Resultados inesperados Orden importa No se pueden ejecutar en paralelo Localización del estado desacotado.
- 45. Estados Globales OcultosSystem.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
- 48. CreditCard@TestpublicvoidcreditCardChargeTest() {CreditCardcc = new CreditCard(“1234567890”);cc.charge(200);}
- 49. CreditCard@TestpublicvoidcreditCardChargeTest() {CreditCardcc = new CreditCard(“1234567890”);cc.charge(200);}java.lang.NullPointerException at talk2.CreditCard.charge(CreditCard.java:48)
- 50. CreditCard@TestpublicvoidcreditCardChargeTest() {CreditCardProcessor.init(…);CreditCardcc = new CreditCard(“1234567890”);cc.charge(200);}
- 51. CreditCard@TestpublicvoidcreditCardChargeTest() {CreditCardProcessor.init(…);CreditCardcc = new CreditCard(“1234567890”);cc.charge(200);}java.lang.NullPointerException at talk2.CreditCardProcessor.init(CreditCardProcessor.java:134)
- 52. CreditCard@TestpublicvoidcreditCardChargeTest() {OfflineQueue.start();CreditCardProcessor.init(…);CreditCardcc = new CreditCard(“1234567890”);cc.charge(200);}
- 53. CreditCard@TestpublicvoidcreditCardChargeTest() {OfflineQueue.start();CreditCardProcessor.init(…);CreditCardcc = new CreditCard(“1234567890”);cc.charge(200);}java.lang.NullPointerException at talk2.OffileQueue.start (OfflineQueue.java:203)
- 54. CreditCard@TestpublicvoidcreditCardChargeTest() {Database.connect(…);OfflineQueue.start();CreditCardProcessor.init(…);CreditCardcc = new CreditCard(“1234567890”);cc.charge(200);}
- 55. CreditCard¿Se ve un patrón?
- 56. CreditCardMiente sobre sus dependencias.El orden de las inicializaciones no es explicito.
- 58. CreditCard (Refactorizado)@TestpublicvoidcreditCardChargeTest() {Databasedb = Database(“connectionStr”);OfflineQueuequeue = new OfflineQueue(db);CreditCardProcessorccProcessor = new CreditCardProcessor(queue);CreditCardcc = new CreditCard(“1234567890”, ccProcesor);cc.charge(200);}
- 60. CreditCardPero… ¿Y si termino con 20 parámetros? Es porque los tenias… solo que…
- 62. Accounting 101classAccountView {Useruser;publicAccountView() {user = RPCClient.getInstance().getUser();}}
- 63. Análisis Uso de Estados GlobalesIncorpora las dependencias del “singleton”Miente a cerca de las dependencias.
- 64. Accounting 101classAccountView {Useruser;publicAccountView(Useruser) {user = user;}}
- 65. ¿Por qué?Construcción de objetos Trabajo en el constructorEstados globalesViolaciones 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. ServiceLocatorAka. Context, aka. Registry… etc.Mejor que un singletonAl 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. ServiceLocatorClassHouse { //… publicHouse(Locatorlocator) { //… Qué tengo que mockear??? }}
- 70. HouseClassHouse {//…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ónSe necesita tener una interface para testearSi 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álisisPara testear se hace complicadoLas 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 MockeryCosas a tener en cuenta.Tiempo de vida de los objetos que se pasan. Ej. Cookie puede ser distinto para cada vez