Unit Testing - Trovit

Unit Testing @jordi9 4 noviembre 2011

roadmap Definición Primer test Excusas Tipos de tests <3 Mockito Código testeable Q & A #trovitrocks http://bitbucket.org/jordi9/gtug-unit-testing http://slideshare.net/giro9

definición Código (método) que ejecuta un otro código para comprobar su validez. ... todos hemos escrito unit tests (o algo parecido) características Automático y repetible Fácil de implementar. Cualquiera puede ejecutarlo "apretando un botón" Debe ser rápido (<1ms)

nuestro primer test frameworks xUnit family: SUnit, JUnit, NUnit, PHPUnit... Nos facilitan como escribir un test, ejecutarlo y obtener resultados. esquema básico de un test System Under Test (SUT) Precondición - Ejecución - Postcondición setup > excercise > verify > teardown postcondición...? Assert assertTrue(boolean); assertEquals(expected, actual); (...) Hamcrest assertThat(foo, is("foo")); assertThat(bar, is(not("foo"))); assertThat(list, hasSize(9));

test con junit public class StringsTest { @Test public void stripAllHTMLForAGivenText() { String html = "<a>Link</a>"; assertThat(Strings.stripHTML(html), is("Link")); } } public class Strings { public static String stripHTML(String input) { return input.replaceAll("</?+(\\b)[ˆ<>]++>", ""); } } unit test

unit test...? // Class under test CreditCardProcessor creditCardProcessor; @Test public void chargeCreditCard() { creditCardProcessor = new CreditCardProcessor(); CreditCard c = new CreditCard("9999 0000 7777", 5, 2009); creditCardProcessor.charge(c, 30.0); assertThat (creditCardProcessor.balance(c), is(-30.0)); } public CreditCardProcessor() { } Mi tarjeta tenía 30 Euros menos!

test con dependencias / mocks Dependencias falsas: mocks frameworks fases "expect" - "replay" - "verify"

preparando un test @Before @After Se ejecutan por cada test unitario public class DatabaseTest { @Before public void prepareFakeDatabase() {} @After public void cleanupFakeDatabase() {} } @BeforeClass @AfterClass Se ejecutan una vez por un conjunto de test public class DatabaseTest { @BeforeClass public static void prepareRealDatabase() {} @AfterClass public static void cleanupRealDatabase() {} }

fixtures preconditions Transient fresh fixtures Cada test construye su fixture cada vez y para el solo. Muy fácil de mantener -- Tests totalmente independientes Sirve como Test as Documentation + Minimal Fixture No teardown -- Implicito Persistent fresh fixtures Tests de integración Caso claro: Tests con base de datos Teardown Shared fixtures Reutilizamos los fixture entre varios tests pero... Rompemos la regla de oro: Keep Tests Independent ... =\ Problemas infinitos: Erratic Tests , Obscure Test http://goo.gl/oxpca | http://goo.gl/22Q19 Difícil de mantener: Fragile Fixture http://goo.gl/TDUw0

más opciones junit testeando excepciones @Test(expected=IllegalArgumentException.class) public void emptyInputShouldRaiseAnException() { Strings.stripHTML(""); } tests con timeout @Test(timeout=1000) public void timeoutFirst() { Strings.veryLongMethod("foo"); } ignorar un test @Ignore("Some very good reason") @Test(timeout=1000) public void timeoutFirst() { Strings.veryLongMethod("foo"); }

detectar código no testeable new 's encapsulados Coste de construcción Estado global API's que engañan

new 's encapsulados class House { Kitchen kitchen = new Kitchen(); Bedroom bedroom; House() { bedroom = new Bedroom(); } }

new 's encapsulados class House { Kitchen kitchen = new Kitchen(); Bedroom bedroom; House() { bedroom = new Bedroom(); } } class HouseTest { @Test public void thisIsReallyHard() { House house = new House(); // Oops... y si quiero utilizar otra cocina u otra // habitación? } }

new 's encapsulados fixed class House { Kitchen kitchen; Bedroom bedroom; @Inject // Guice! House(Kitchen kitchen, Bedroom bedroom) { this.kitchen = kitchen; this.bedroom = bedroom; } }

new 's encapsulados fixed class House { Kitchen kitchen; Bedroom bedroom; @Inject // Guice! House(Kitchen kitchen, Bedroom bedroom) { this.kitchen = kitchen; this.bedroom = bedroom; } } class HouseTest { @Test public void thisIsCoolAndFlexible() { Kitchen kitchen = new FooKitchen(); Bedroom bedroom = new InexpensiveBedroom(); House house = new House(kitchen, bedroom); // yay! } }

Coste de construcción class Car { Engine engine; Car(File file) { String model = readEngineModel(file); // expensive method engine = new EngineFactory().create(model); } } Para instanciar un objeto: Tienes que navegar por todo lo que se haga en la constructora. No puedes sobrescribirla.

Coste de construcción class Car { Engine engine; Car(File file) { String model = readEngineModel(file); // expensive method engine = new EngineFactory().create(model); } } class CarTest { public void noSeamForFakeEngine() { // Aggh! Ficheros en los unit tests... File file = new File("engine.config"); Car car = new Car(file); // Quiero utilizar otro motor pero no puedo por culpa // de la fábrica... } } Para instanciar un objeto: Tienes que navegar por todo lo que se haga en la constructora. No puedes sobrescribirla.

Coste de construcción class Car { Engine engine; Car(Engine engine) { this.engine = engine; } } @Provides // más Guice! Engine providesEngine(EngineFactory engineFactory, @EngineModel String model) { return engineFactory.create(model); }

Coste de construcción class Car { Engine engine; Car(Engine engine) { this.engine = engine; } } @Provides // más Guice! Engine providesEngine(EngineFactory engineFactory, @EngineModel String model) { return engineFactory.create(model); } @Test public void nowWeHaveACleanDesign() { Engine fakeEngine = new FakeEngine(); Car car = new Car(fakeEngine); } Hacer el mínimo trabajo posible en la constructora

Estado global Repetir el mismo proceso y obtener un resultado diferente... ugh! síntomas Orden de los tests importa (prohibido!) No se pueden ejecutar los tests en paralelo ejemplos En la propia JVM tenemos malos ejemplos: System.currentTime(); new Date(); Math.random() Testear el código anterior es muy difícil.

APIs engañosas Dependencias ocultas... recuperemos el ejemplo de antes @Test public void chargeCreditCard() { CreditCard cc = new CreditCard("9999 0000 7777", 5, 2009); cc.charge(30.0); } java.lang.NullPointerExpection at com.trovit.unittesting.C reditCard.charge()

APIs engañosas @Test public void chargeCreditCard() { CreditCardProcessor.init(); CreditCard cc = new CreditCard("9999 0000 7777", 5, 2009); cc.charge(30.0); } java.lang.NullPointerExpection at com.trovit.unittesting .C reditCardProcessor.init()

APIs engañosas @Test public void chargeCreditCard() { OfflineQueue.start(); CreditCardProcessor.init(); CreditCard cc = new CreditCard("9999 0000 7777", 5, 2009); cc.charge(30.0); } java.lang.NullPointerExpection at com.trovit.unittesting .OfflineQueue .start()

APIs engañosas @Test public void chargeCreditCard() { Database.connect(...); OfflineQueue.start(); CreditCardProcessor.init(); CreditCard cc = new CreditCard("9999 0000 7777", 5, 2009); cc.charge(30.0); } La API de CreditCard nos engaña: No expone sus dependencias de manera clara. Pretende no necesitar la CreditCardProcessor pero lo hace. Aun pierdo 30 Euros! Si tu código depende del orden en que se inician los Singletons... está documentado en alguna parte? Quien no se ha encontrado esto nunca? ;) La solución es Dependency Injection: Te fuerza el orden correcto en tiempo de compilación.

una solución mejor @Test public void chargeCreditCard() { db = new Database(...); queue = new OfflineQueue( db ); ccProc = new CreditCardProcessor( queue ); CreditCard cc = new CreditCard( ccProc , "9999 0000 7777"); cc.charge(30.0); }

muchísimas más cosas! más frameworks DbUnit WebDriver / Selenium 2 MockRunner Android: ActivityInstrumentationTestCase ActivityUnitTestCase metodologías Test Driven Development (<3) Acceptance Test Continous Integration / Jenkins utilidades Test coverage: Cobertura / Clover Testability Explorer

gracias! jordi9 @trovit.com @jordi9

Q & A jordi9 @trovit.com @jordi9

Unit Testing - Trovit

Más contenido relacionado

La actualidad más candente (20)

Similar a Unit Testing - Trovit (20)

Más de Jordi Gerona (6)

Unit Testing - Trovit

Notas del editor