Jan 13, 2015
TDD: FRA FIZZBUZZ TIL PRAKTISK BRUK I PROSJEKT, OG HVORDAN JEG SKRIVER
TESTER
90 min workshop
Smidig 2011
Jonas Follesø
14//11
LITT OM MEG
Scientist BEKK Trondheim
Aktiv i .NET fagmiljøetBrukt TDD siden 2006
Jonas Follesø
LITT OM DERE?
AGENDA
Essensen i TDD
Feedback Loops
Lesbare tester
Mocking
Builder Pattern
Satna Wish List Processor
RØD, GRØNN, REFAKTORER FEEDBACK LOOP I TDD
TDD GIR OSS TILBAMELEDINGER PÅ
Design(er koden
vellstrukturert)
Implementasjon
(virker koden)
TEST OPPFØRSEL – IKKE METODER
I begynnelsen skrev vi tester som «speiler» klassen som testes
public class OrderProcessing{ public void ProcessOrder(Order order){} public void ShipOrder(Order order){}}
[TestFixture]public class OrderProcessingTest{ [Test] public void ProcessOrderTest(){}
[Test] public void ShipOrderTest(){}
[Test] public void ShipOrderTest2(){}}
TEST OPPFØRSEL – IKKE METODER
“I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD”
- Dan North, Introducing BDD blog post
TESTDOX NAVNEKONVENSJON
Hver test er en setning med klassen som testes som implisitt subjekt
• A List holds items in the order they were added
• A List can hold multiple references to the same item
• A List throws an exception when removing an item it
doesn’t hold
TESTKLASSE SKREVET ETTER TESTDOX KONVENSJON[TestFixture]public class ListTest{
[Test] public void Holds_items_in_the_order_they_were_added() { }
[Test] public void Can_hold_multiple_references_to_the_same_item() { }
[Test] public void Throws_exception_when_removing_an_item_it_doesnt_hold() { }
}
KLASSEVARIABLER I BUNNEN AV KLASSEN
[TestFixture]public class OrderProcessingTest{ [Test] public void Should_generate_shipping_statement_for_order() { }
[SetUp] public void Given_we_have_an_order_processor() { emailService = new EmailMock(); processor = new OrderProcessing(emailService); }
private OrderProcessing processor; private EmailMock emailService;}
ARRANGE, ACT, ASSERT
[Test]public void Should_read_inbox_location(){ string[] parameters = {@"c:\inbox", ""};
var initParameter = new InitParameters(parameters);
initParameter.Inbox.Should().Be(@"c:\inbox");}
EKSEMPLER PÅ ASSERTS
[Test]public void Standard_NUnit_Asserts(){ string input = "Merry Christmas"; Assert.That(input, Is.EqualTo("Merry Christmas"));}
[Test]public void NUnit_Should_Asserts(){ string input = "Merry Christmas"; input.Should(Be.EqualTo("Merry Christmas"));}
[Test]public void Fluent_Asserts(){ string input = "Merry Christmas"; input.Should().Be("Merry Christmas");}
NUNIT SHOULD ASSERTS
public class Be : Is { public Be() { } }public class Have : Has { public Have() { } }public class Contain : Contains { public Contain() { } }
public static partial class ShouldExtensions{ public static void Should(this object o, IResolveConstraint constraint) { Assert.That(o, constraint); } public static void ShouldNot(this object o, Constraint constraint) { Assert.That(o, new NotOperator().ApplyPrefix(constraint)); }}
FLUENT ASSERTS
input.Should().Be("Merry Christmas");
public static class MyFluentAsserts{ public static StringAsserts Should(this string text) { return new StringAsserts(text); }}
public class StringAsserts{ private readonly string _text;
public StringAsserts(string text) { _text = text; }
public void Be(string otherString) { Assert.That(_text, Is.EqualTo(otherString)); }}
STANDARD NUNIT ASSERTS
[Test]public void Standard_NUnit_Asserts(){ string input = "Merry Christmas"; Assert.That(input, Is.EqualTo("Merry Christmas"));}
[Test]public void NUnit_Should_Asserts(){ string input = "Merry Christmas"; input.Should(Be.EqualTo("Merry Christmas"));}
[Test]public void Fluent_Asserts(){ string input = "Merry Christmas"; input.Should().Be("Merry Christmas");}
ET EKSTRA STEG I TDD-PROSESSEN
IKKE LESBAR FEILMELDING
[Test]public void Non_readable_diagnostics(){ string input = "Merry Christmas"; Assert.True(input == "Merry christmas");}
------ Test started: Assembly: SantaWorkshop.Tests.dll ------
Test 'SantaWorkshop.Tests.TempTest.Non_readable_diagnostics' failed: Expected: True But was: FalseTempTest.cs(35,0): at SantaWorkshop.Tests.TempTest.Non_readable_diagnostics()
0 passed, 1 failed, 0 skipped, took 0,55 seconds (NUnit 2.5.5).
LESBAR FEILMELDING[Test]public void Readable_diagnostics(){ string input = "Merry Christmas"; Assert.That(input, Is.EqualTo("Merry christmas"));}
------ Test started: Assembly: SantaWorkshop.Tests.dll ------
Test 'SantaWorkshop.Tests.TempTest.Readable_diagnostics' failed: String lengths are both 15. Strings differ at index 6. Expected: "Merry christmas" But was: "Merry Christmas" -----------------^TempTest.cs(42,0): at SantaWorkshop.Tests.TempTest.Readable_diagnostics()
0 passed, 1 failed, 0 skipped, took 0,37 seconds (NUnit 2.5.5).
ET EKSTRA STEG I TDD-PROSESSEN
FOKUS PÅ LESBARHET
Som utvikler bruker vi langt mere tid på å lese kode enn å skrive kode
• Lett å forstå hva koden gjør gjennom testnavn
• Lett å forstå hvordan bruke koden gjennom test implementasjon
• Lett å forstå hvorfor en test feiler når koden endrer seg
• Lett å forstå hvordan koden er implementert gjennom kontinuerlig refaktorering og fokuserte/små klasser
TESTENE BLIR LEVENDE DOKUMENTASJON
LESBARHET
Testkode beskriver hva koden
gjør. Konkret i verdiene som
brukes som eksempler på hva
koden gjør, og til å verifisere at
den faktisk gjør det, men
abstrakt i hvordan koden
fungerer
Produksjonskode er absrrakt i
verdiene som brukes, men
konkret i hvordan den får
jobben gjort.
HVOR BEGYNNER VI?
Tester fra utsiden og inn for å hele tiden fokusere på funksjonalitet som gir verdi
Begynner å teste et «skjelet» som tar for seg den enkleste funksjonaliteten som gir mening
Skrive en ende-til-ende akseptansetest som vil «tvinge oss» til å begynne på den faktiske implementasjonen
TEST ET «VANDRENDE SKJELETT»
AKSEPTANSETEST SOM YTRE FEEDBACK LOOP
ATDD I ET STØRRE PERSPEKTIV
UNIT, INTEGRATION & ACCEPTANCE TEST
• Tester vår kode
• Uavhengig av miljø
• Kjører raskt
• Tester hvordan vår kode integrerer med kode vi ikke kontrollerer
• Kan røre miljø (filsystem, meldingskø)
• Tester systemet ende-til-ende
• Fokus på brukerhistorier
• Bruker så realistisk miljø som mulig
Unit TestIntegration
TestAcceptance
Test
CASE: SANTA WISHLIST PROCESSOR ITERASJON 1
• Julenissen mottar store mengder ønskelister til jul.
• Ønsker system for å effektivisere behandlingen av disse.
• Systemet skal være batch-basert, og lese innkommende ønskelister som skal gjøres om til utgående pakke- og leveranselister
• Skal kjøre som en Console Application som f.eks kan settes opp som en scheduled task
• Første iterasjon gir alle barn det de har ønsket seg aller mest
CASE: SANTA WISHLIST PROCESSOR INPUT/OUTPUT FORMAT
Input filformat:
Jonas Follesø (28)Wesselsgate 19, 7043 Trondheim
Nokia Lumia 800
iPhone 4S
iPad 2
Output filformat:
Nokia Lumia 800 (Jonas Follesø, Wesselsgate 19, 7043 Trondheim)
iPhone 4S (Ola Nordman, Kirkeveien 1, 1000 Oslo)
KLASSISK TDD VS «LONON SCHOOL»-TDD
Verifisering av
oppførsel
Verifisering av tilstand
KLASSISK TDD
Kent Beck’s «Test-driven Development By Example»
En algoritme oppdages en test av gangen.
Tester tilstanden til systemet etter
ROMERTALL I KLASSISK TDD
Stegene og testene for å finne romertall for et gitt tall kan se slik ut:
• Test 1: I => return «I»
• Test 2: II => if (number == 1) return «I» else return «II»
• Test 3: III => while (number > 0) concat «I» to result and decrement number
Verifisering av tilstand
KLASSISK TDD
Vi lager en mer generell løsning en test av gangen, slik at vi til slutt ender opp med en enkel, elegant løsning som håndterer alle testene opp til nå
«LONDON STYLE»-TDD / MOCKIST TDD
«Growing Object Oriented Software Guided by Tests» den definitive boka.
Fokus på:
• Roller
• Ansvarsområder
• Interaksjon
Verifisering av
oppførsel
ET NETTVERK AV OBJEKTER
HVOR VI ØNSKER Å TESTE ETT OBJEKT FOR SEG
HVOR VI ØNSKER Å TESTE ETT OBJEKT FOR SEG
TESTING MED MOCK OBJEKTER
Verifisering av
oppførsel
TESTING MED MOCK OBJEKTER
[Test]public void Should_send_email_when_order_is_processed(){ var emailMock = new Mock<ISendEmail>();
emailMock.Setup(e => e.SendMessage(It.Is<Message>(m => m.To == "[email protected]"))) .Returns(true) .Verifiable("Did not send e-mail to customer as expected");
var orderProcessing = new OrderProcessing(emailMock.Object); var order = new Order {CustomerEmail = "[email protected]"}; orderProcessing.ProcessOrder(order); emailMock.Verify();}
TESTING MED MOCK OBJEKTER
Test 'Should_send_email_when_order_is_processed' failed: Moq.MockVerificationException : The following setups were not matched:Did not send e-mail to customer as expected: ISendEmail e => e.SendMessage(It.Is<Message>(m => m.To == "[email protected]"))
TESTING MED HÅNDSKREVET MOCK
[Test]public void Should_send_email_when_order_is_processed(){ var emailMock = new EmailMock(); var orderProcessing = new OrderProcessing(emailMock);
var order = new Order {CustomerEmail = "[email protected]"}; orderProcessing.ProcessOrder(order);
emailMock.SendMessageWasCalled.Should().BeTrue("Should send e-mail to customer"); emailMock.MessageThatWasSent.To.Should().Be("[email protected]");}
TESTING MED HÅNDSKREVET MOCK
Test ‘Should_send_email_when_order_is_processed' failed: Expected True because Should send e-mail to customer, but found False.
EMAILMOCK KLASSE
public class EmailMock : ISendEmail{ public Message MessageThatWasSent; public bool SendMessageWasCalled; public Exception ExceptionToThrow; public bool ReturnValue;
public bool SendMessage(Message message) { SendMessageWasCalled = true; MessageThatWasSent = message;
if(ExceptionToThrow != null) throw ExceptionToThrow;
return ReturnValue; }}
MOCK RAMMEVERK ELLER HÅNDSKREVNE MOCKS?Mock Rammeverk
• Mulighet for avansert matching på parametere
• Slipper å skrive enge mock klasser
• Presise feilmeldinger på hvilke expectations som ikke ble møtt
Håndskrevne Mocks
• Lett å forstå for «nybegynnere»
• Lett å debugge gjennom koden
TESTING MED MOCK OBJEKTER
Tester hvordan vårt objekt sammarbeider med objektene rundt seg
Gjennom å skrive tester på denne måten designer vi både det inngående og utgående grensesnittet til klassen
Inngående grensesnitt er metoder på klassen
Utgående grensesnitt er avhengigheter, og metodene vi kaller på disse klassene
Verifisering av
oppførsel
TESTING MED MOCK OBJEKTER
Verifisering av
oppførsel
KLASSISK TDD VS «LONON SCHOOL»-TDD
Verifisering av
oppførsel
Verifisering av tilstand
DRIVKREFTER FOR DESIGN
Higher level of
abstractions
Seperation of concerns
PORTS AND ADAPTERS
Integration /Acceptanc
e Test
Unit Test
ARKITEKTUREN OG DESIGNET SOM VIL VOKSE FRAM
Integration /Acceptanc
e Test
Unit Test
OPPSETT AV TESTDATA
[Test]public void Should_generate_shipping_statement_for_order(){ var order = new Order { Customer = new Customer { Name = "Jonas Follesø", Address = new Address { City = "Lakselv", PostalCode = 9700 } }, Lines = new List<OrderLine> { new OrderLine { Product = "Some product", Quantity = 1 }, new OrderLine { Product = "Some other product", Quantity = 2 } } };
var orderProcessing = new OrderProcessing(); orderProcessing.ProcessOrder(order);}
PROBLEMER MED TESTDATA
• Vanskelig å se hvilke felter som har betyrning for testen
• Testene blir mer skjøre mot endringer i datastruktur
• Testene ikke like enkle å lese
• Bruker vi «immutable value types» (DDD) må feltene settes i konstruktør
TESTDATA MED BUILDER PATTERN
[Test]public void Should_generate_shipping_statement_for_order(){ Order order = Build
.AnOrder() .ForCustomer(CustomerBuilder.ACustomer()) .WithLine("Some product", quantity: 1) .WithLine("Some other product", quantity: 2);
var orderProcessing = new OrderProcessing(); orderProcessing.ProcessOrder(order);}
BUILDER PATTERN IMPLEMENTASJONpublic class CustomerBuilder{ private Customer customer;
public static CustomerBuilder ACustomer() { return new CustomerBuilder(); }
private CustomerBuilder() { customer = new Customer(); customer.Name = "John Doe"; }
public static implicit operator Customer(CustomerBuilder builder) { return builder.customer; }}
BUILDER PATTERN IMPLEMENTASJON
public CustomerBuilder WithName(string name){ customer.Name = name; return this;}
public CustomerBuilder WithAddress(Address address){ customer.Address = address; return this;}
BUILDER PATTERN FACTORY
public static class Build{ public static CustomerBuilder ACustomer() { return CustomerBuilder.ACustomer(); }
public static OrderBuilder AnOrder() { return OrderBuilder.AnOrder(); }}
TESTDATA MED BUILDER PATTERN
[Test]public void Should_generate_shipping_statement_for_order(){ Order order = Build .AnOrder() .ForCustomer(CustomerBuilder.AnCustomer()) .WithLine("Some product", quantity: 1) .WithLine("Some other product", quantity: 2);
var orderProcessing = new OrderProcessing(); orderProcessing.ProcessOrder(order);}
TESTDATA MED BUILDER PATTERN
Don’t repeat yourself
Lesbarhet
CASE: SANTA WISHLIST PROCESSOR ITERASJON 2
• Svært kostbart at alle skal få det de har ønsket seg
• Ønsker å sjekke om barn har vært snille eller ikke. Denne informasjonen ligger i SC(R)UM (Santa Clause Relationship and Uber Management System)
• Integration med SC(R)UM er outsourcet til Finland, så vi skal kun definere grensesnittet mot deres tjenester.
• Kun barn under 18 som har vært snill får pakken sin
CASE: SANTA WISHLIST PROCESSOR ITERASJON 3
• Ønsker å fordele hvilke gaver som skal gis basert på lagerstatus. Skal derfor velge den gaven fra ønskelisten som det er flest av på lager
• Har hatt problemer med å finne adressen. Ønsker derfor å bruke RPS (Rudolf Positioning System) som finner en nøyaktig posisjon for en gitt adresse.
REFERANSE: CLASSIC TDD OR «LONDON SCHOOL»
http://bit.ly/LondonVsClassic
REFERANSE: MOCKS AREN'T STUBS
http://bit.ly/MocksArentStubs
REFERANSE: MOCKING MOCKING AND TESTING OUTCOMES
http://bit.ly/MockingMocking
REFERANSE: GROWING OBJECT ORIENTED SOFTWARE GUIDED BY TESTS
http://www.growing-object-oriented-software.com/
TAKK FOR MEG!
Spørsmål?