Embed Size (px)
DESCRIPTION
Citation preview
Unit Testing
@jordi94 noviembre 2011
roadmapDefinició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ísticasAutomático y repetibleFácil de implementar.Cualquiera puede ejecutarlo "apretando un botón"Debe ser rápido (<1ms)
nuestro primer testframeworksxUnit family: SUnit, JUnit, NUnit, PHPUnit...Nos facilitan como escribir un test, ejecutarlo y obtener resultados.
esquema básico de un testSystem Under Test (SUT)Precondición - Ejecución - Postcondición setup > excercise > verify > teardown
postcondición...? AssertassertTrue(boolean);assertEquals(expected, actual);(...)
HamcrestassertThat(foo, is("foo")); assertThat(bar, is(not("foo"))); assertThat(list, hasSize(9));
ejemplo
primer test
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
tipos de test
by @mhevery
excusas...
by @mhevery
unit test...?
// Class under test CreditCardProcessor creditCardProcessor;
@Testpublic 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"
ejemplo
<3 mockito
preparando un test@Before @AfterSe ejecutan por cada test unitario
public class DatabaseTest { @Before public void prepareFakeDatabase() {}
@After public void cleanupFakeDatabase() {}}
@BeforeClass @AfterClassSe 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 fixturesCada 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 fixturesTests de integración Caso claro: Tests con base de datos Teardown
Shared fixturesReutilizamos 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 junittesteando 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");}
ejemplo
/etc/junit
detectar código no testeable
new's encapsulados
Coste de construcción
Estado global
API's que engañan
new's encapsuladosclass House { Kitchen kitchen = new Kitchen(); Bedroom bedroom;
House() { bedroom = new Bedroom(); }}
new's encapsuladosclass 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 fixedclass House { Kitchen kitchen; Bedroom bedroom;
@Inject // Guice! House(Kitchen kitchen, Bedroom bedroom) { this.kitchen = kitchen; this.bedroom = bedroom; }}
new's encapsulados fixedclass 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ónclass 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ónclass Car { Engine engine; Car(Engine engine) { this.engine = engine; }}
@Provides // más Guice!Engine providesEngine(EngineFactory engineFactory, @EngineModel String model) { return engineFactory.create(model);}
@Testpublic void nowWeHaveACleanDesign() { Engine fakeEngine = new FakeEngine(); Car car = new Car(fakeEngine);}
Hacer el mínimo trabajo posible en la constructora
Estado globalRepetir el mismo proceso y obtener un resultado diferente... ugh!
síntomasOrden de los tests importa (prohibido!)No se pueden ejecutar los tests en paralelo
ejemplosEn la propia JVM tenemos malos ejemplos: System.currentTime(); new Date(); Math.random()
Testear el código anterior es muy difícil.
APIs engañosasDependencias ocultas... recuperemos el ejemplo de antes
@Testpublic void chargeCreditCard() { CreditCard cc = new CreditCard("9999 0000 7777", 5, 2009); cc.charge(30.0);}
java.lang.NullPointerExpection at com.trovit.unittesting.CreditCard.charge()
APIs engañosas@Testpublic void chargeCreditCard() { CreditCardProcessor.init(); CreditCard cc = new CreditCard("9999 0000 7777", 5, 2009); cc.charge(30.0);}
java.lang.NullPointerExpection at com.trovit.unittesting.CreditCardProcessor.init()
APIs engañosas@Testpublic 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@Testpublic 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@Testpublic 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 frameworksDbUnitWebDriver / Selenium 2MockRunnerAndroid: ActivityInstrumentationTestCase ActivityUnitTestCase
metodologíasTest Driven Development (<3)Acceptance TestContinous Integration / Jenkins
utilidadesTest coverage: Cobertura / CloverTestability Explorer
