• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Smidig 2011 TDD Workshop
 

Smidig 2011 TDD Workshop

on

  • 1,318 views

Presentation from TDD workshop at Smidig 2011 hosted by Jonas Follesø.

Presentation from TDD workshop at Smidig 2011 hosted by Jonas Follesø.

The slides are in Norwegian.

Statistics

Views

Total Views
1,318
Views on SlideShare
1,315
Embed Views
3

Actions

Likes
0
Downloads
7
Comments
0

2 Embeds 3

http://a0.twimg.com 2
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • A better alternative is to name tests in terms of the features that the target object provides.We use a TestDox convention (invented by Chris Stevenson) where each test name reads like a sentence, with the target class as the implicit subject.

Smidig 2011 TDD Workshop Smidig 2011 TDD Workshop Presentation Transcript

  • TDD: FRA FIZZBUZZ TILPRAKTISK BRUK I PROSJEKT, OGHVORDAN JEG SKRIVER TESTER 90 min workshop Smidig 2011 Jonas Follesø 14//11
  • LITT OM MEG Jonas Follesø Scientist BEKK Trondheim Aktiv i .NET fagmiljøet Brukt TDD siden 2006
  • LITT OM DERE?
  • AGENDA Essensen i TDD Feedback Loops Lesbare tester Mocking Builder Pattern Satna Wish List Processor
  • RØD, GRØNN, REFAKTORERFEEDBACK LOOP I TDD
  • TDD GIR OSS TILBAMELEDINGER PÅ Design Implementasjon (er koden (virker koden) vellstrukturert)
  • TEST OPPFØRSEL – IKKE METODERI begynnelsen skrev vi tester som «speiler» klassen som testespublic 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 tothinking in behaviour so profound that Istarted to refer to TDD as BDD” - Dan North, Introducing BDD blog post
  • TESTDOX NAVNEKONVENSJONHver test er en setning med klassen som testes som implisittsubjekt• 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 ASSERTSpublic 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 ASSERTSinput.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_diagnosticsfailed: Expected: True But was: FalseTempTest.cs(35,0): atSantaWorkshop.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_diagnosticsfailed: String lengths are both 15. Strings differ at index 6. Expected: "Merry christmas" But was: "Merry Christmas" -----------------^TempTest.cs(42,0): atSantaWorkshop.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Å LESBARHETSom 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
  • LESBARHETTestkode beskriver hva koden gjør. Produksjonskode er absrrakt iKonkret i verdiene som brukes som verdiene som brukes, men konkret ieksempler på hva koden gjør, og til å hvordan den får jobben gjort.verifisere at den faktisk gjør det, menabstrakt i hvordan koden fungerer
  • HVOR BEGYNNER VI? TEST ET «VANDRENDE SKJELETT» 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
  • AKSEPTANSETEST SOM YTRE FEEDBACK LOOP
  • ATDD I ET STØRRE PERSPEKTIV
  • UNIT, INTEGRATION &ACCEPTANCE TEST Unit Test Integration Test Acceptance Test• Tester vår kode • Tester hvordan vår kode • Tester systemet ende-til- integrerer med kode vi ende• Uavhengig av miljø ikke kontrollerer • Fokus på brukerhistorier• Kjører raskt • Kan røre miljø (filsystem, • Bruker så realistisk miljø meldingskø) som mulig
  • 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 FORMATInput filformat:Jonas Follesø (28)Wesselsgate 19, 7043 TrondheimNokia Lumia 800iPhone 4SiPad 2Output 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 Verifisering av tilstand oppførsel
  • KLASSISK TDDKent Beck’s «Test-driven Development By Example»En algoritme oppdages en test av gangen.Tester tilstanden til systemet etter
  • ROMERTALL I KLASSISK TDDStegene 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 TDDVi lager en mer generell løsning en test av gangen, slik at vitil slutt ender opp med en enkel, elegant løsning somhåndterer alle testene opp til nå
  • «LONDON STYLE»-TDD / MOCKIST TDD«Growing Object Oriented Software Guided by Tests» dendefinitive 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 == "jonas@follesoe.no"))) .Returns(true) .Verifiable("Did not send e-mail to customer as expected"); var orderProcessing = new OrderProcessing(emailMock.Object); var order = new Order {CustomerEmail = "jonas@follesoe.no"}; orderProcessing.ProcessOrder(order); emailMock.Verify();}
  • TESTING MED MOCK OBJEKTERTest 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 =="jonas@follesoe.no"))
  • 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 = "jonas@follesoe.no"}; orderProcessing.ProcessOrder(order); emailMock.SendMessageWasCalled.Should().BeTrue("Should send e-mail to customer"); emailMock.MessageThatWasSent.To.Should().Be("jonas@follesoe.no");}
  • TESTING MED HÅNDSKREVET MOCKTest ‘Should_send_email_when_order_is_processed failed: ExpectedTrue because Should send e-mail to customer, but found False.
  • EMAILMOCK KLASSEpublic 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 ELLERHÅNDSKREVNE MOCKS?Mock Rammeverk Håndskrevne Mocks• Mulighet for avansert matching på • Lett å forstå for «nybegynnere» parametere • Lett å debugge gjennom koden• Slipper å skrive enge mock klasser• Presise feilmeldinger på hvilke expectations som ikke ble møtt
  • TESTING MED MOCK OBJEKTERTester hvordan vårt objekt sammarbeider med objektene rundt segGjennom å skrive tester på denne måten designer vi både det inngående ogutgående grensesnittet til klassenInngående grensesnitt er metoder på klassenUtgå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 Verifisering av tilstand oppførsel
  • DRIVKREFTER FOR DESIGN Seperation of Higher level of concerns abstractions
  • PORTS AND ADAPTERS Unit TestIntegration/Acceptance Test
  • ARKITEKTUREN OG DESIGNET SOM VIL VOKSE FRAM Unit Test Integration /Acceptance 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 IMPLEMENTASJONpublic CustomerBuilder WithName(string name){ customer.Name = name; return this;}public CustomerBuilder WithAddress(Address address){ customer.Address = address; return this;}
  • BUILDER PATTERN FACTORYpublic 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 Lesbarhet yourself
  • 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 ARENT STUBShttp://bit.ly/MocksArentStubs
  • REFERANSE: MOCKING MOCKING AND TESTING OUTCOMEShttp://bit.ly/MockingMocking
  • REFERANSE: INTRODUCING BDDhttp://bit.ly/DanBDD
  • REFERANSE: GROWING OBJECT ORIENTED SOFTWARE GUIDED BY TESTShttp://www.growing-object-oriented-software.com/
  • Spørsmål?TAKK FOR MEG!