Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Test Smarter, Not Harder

Marek Matulka
November 25, 2024
31

Test Smarter, Not Harder

Testing your application is hard. Writing tests seems like a never ending story of database fixture changes. Some parts of your system seem like they can't be tested. When using a framework, it may feel like you're stuck with functional/feature testing only. Your test suite grows and becomes slower over time. At some point, it may feel like it's no longer serving its purpose.

Learn how to build your own testing strategy. Learn how to apply the right amount of testing at the appropriate level, to make your tests run faster.

Talk inspired by "Lightning Fast Tests" talk by Jakub Zalas.

Marek Matulka

November 25, 2024
Tweet

More Decks by Marek Matulka

Transcript

  1. Different types of tests Manual testing End-2-end testing UI testing

    Integration testing Acceptance testing Service testing Unit testing
  2. Functional/feature/integration testing Manual testing End-2-end testing UI testing Integration testing

    Acceptance testing Service testing Unit testing Controller Repository Service A Api Service B Service C
  3. Unit testing Manual testing End-2-end testing UI testing Integration testing

    Acceptance testing Service testing Unit testing Controller Service A Service B Service C
  4. (Lack of) speed is not only the issue Fast Reliable

    Good feedback Grow linearly Force better design Isolated Slow Fragile Poor feedback Grow exponentially Put pressure off design Can simulate user journeys Unit tests Feature/Functional tests
  5. Let's implement ticket price calculator • a simple service that

    calculates taxes for given route • tickets with fare information are stored in the local database • taxes are provided by a third party API for route and fare
  6. Two sides of the contract TicketPriceCalculator TicketRepository TaxCalculator DoctrineTicketRepository •

    An interface is a contract • User of the interface makes an assumption about the behaviour with test doubles • Implementation of the interface needs to prove it implements the contract fully • For each expectation in the unit test there should be at least one test to verify that expectation
  7. TicketPriceCalculator EntityManager HttpClient DB HTTP Integration tests Unit tests TicketRepository

    TaxCalculator DoctrineTicketRepository HttpClientExternalApi ExternalApi
  8. TicketPriceCalculator EntityManager HttpClient DB HTTP Integration tests Unit tests TicketRepository

    TaxCalculator DoctrineTicketRepository HttpClientExternalApi ExternalApiTaxCalculator ExternalApi
  9. Write a failing scenario (feature) Write a failing test Make

    your test pass Refactor your code Repeat the fail-pass-refactor cycle as necessary
  10. Write a failing scenario (feature) Write a failing test Make

    your test pass Refactor your code Make your feature pass
  11. Write a failing scenario (feature) Write a failing test Make

    your test pass Refactor your code Make your feature pass BDD TDD
  12. Write a failing scenario (feature) Write a failing test Make

    your test pass Refactor your code Make your feature pass BDD TDD External Quality Internal Quality
  13. Flexible Behat Unit tests Modelling by Example Acceptance tests Use

    Fakes instead of DB/APIs. Smoke tests Verify critical user paths