Unit Tests are Overrated (NDCOslo 2013)

2.197 Aufrufe

Veröffentlicht am

These are the slides from my talk at the Norwegian Developer conference in Oslo 2013 on why unit testing is not necessarily the best way to test our code.

Veröffentlicht in: Technologie, Bildung
0 Kommentare
2 Gefällt mir
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe insgesamt
Auf SlideShare
Aus Einbettungen
Anzahl an Einbettungen
Gefällt mir
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Unit Tests are Overrated (NDCOslo 2013)

  1. 1. Unit Tests are OverratedLars-Erik KindbladSenior ConsultantTwitter: @kindblad
  2. 2. Unit Testing Misconceptions1. Unit tests can talk to a database, web service etc. Not true: That’s integration tests. A unit test tests a class or method in isolation usingstubs or mocks. When people say that unit testing is great they might actually mean integration testing2. Unit tests ensure that a system works 100% Not true: A unit test is not an end-to-end test. It only verifies that the class is working inisolation, it does not verify that it works and integrates with other classes3. Unit tests allow for safe refactoring Not true: Unit tests are too detailed tests. Small refactoring such as splitting a class in twoforces the unit tests to be changed4. Unit tests improve the code quality Not true: Unit tests don’t automatically improve code quality. There are a lot of bad unittested code5. Unit tests reduce the technical debt Not true: Very hard to write good unit tests. Big chance that the technical debt increases
  3. 3. Unit Testing Misconceptions6. 100% unit test coverage means the system is bug free Not true: Code coverage only tells us what was executed by our unit tests, not if it wasexecuted correctly int Foo(int a, int b) { return a / b; }would need more than one test to be verified 100% but one test is enough to get 100%code coverage7. Unit testing can replace the QA resourcesNot true: Developers are really bad at finding bugs Unit tests can have bugs The requirements could have been misunderstood and implemented wrongly8. Unit tests are the documentation Not true: Most developer trust their code more than their unit tests. The code itself shouldbe self documenting
  4. 4. A Better Way – Use Case TestingIntegration tests that focuses on the use casesBusiness LayerInfrastructure Layer (DAL)Presentation/Services LayerEndpointsDatabase Web ServiceFilesystem SMTP Service BusClass ClassClassClassUse Case Tests Assert on: Result from the presentation/serviceslayer Endpoints result or that the endpointshave received the messagesAdvantage: Tests at a higher level than unit tests Safe and fast to refactor Only have to update the tests when thefunctionality changes Verifies the quality from top tobottom, from the start of the use caseto the end Can write the tests based on the QAtest cases
  5. 5. 1. Challenge – Testing the Presentation LayerA lot of changes happens all the time – the tests must be updatedcontinuallyA lot of infrastructure setup and concerns makes it hard to test
  6. 6. SolutionAdd a Use Case Layer for delivery mechanism indepent use casesAdvantage: No dependencies to ASP.NET, WPFor WP. 100% testable through DTO’s Most critical functionality are verifiedDisadvantage: The presentation layer is not verified The Use Cases Layer and the layers below aremost critical, a serious error can corrupt thesystemUse Cases LayerBusiness LayerInfrastructure LayerPresentation LayerUse Case TestsData Transfer ObjectsEndpoints
  7. 7. 2. Challenge – Test Data & Verification Data at the endpoints changes constantly Breaks the tests Impossible to verify the result
  8. 8. Solution 1/2
  9. 9. Solution 2/2
  10. 10. 3. Challenge - Non-Controllable EndpointsDon’t have access to delete and create testdata at the endpointNot possible to verify the result at the endpointCannot verify our use case
  11. 11. Business LogicUse CasesTestsDatabaseSMTPServerSolutionCreate a copy of the existing endpoint to use it for testing onlyReplace the endpoint with a fake endpoint using dependency inversion& the Onion Architecture to verify the flow of the use case- ICustomerRepository- IEmailSender- FakeEmailSender- CustomerRepository- EmailSender
  12. 12. Fake E-Mail Endpoint Implementation
  13. 13. 4. Challenge - Slow TestsTakes too long to runSolution:Better to have slow tests that verify the quality 100% than fast tests that donotReplace the endpoints with fake in-memory endpoints
  14. 14. Test StrategyThe test strategy for my current project:1. Write use case tests to verify the end-to-end quality Important to test both the success- and the fail scenarios2. Write unit tests or integration tests to test complex logic and algorithmssuch as calculations3. When using fake endpoints for testing: Write integration tests to verifythat the basics of the non-fake implementations work.Every project is different = Define your own test strategy!
  15. 15. The information contained in this presentation is proprietary.© 2012 Capgemini. All rights reserved.www.capgemini.comAbout CapgeminiWith more than 120,000 people in 40 countries, Capgemini is oneof the worlds foremost providers of consulting, technology andoutsourcing services. The Group reported 2011 global revenuesof EUR 9.7 billion.Together with its clients, Capgemini creates and deliversbusiness and technology solutions that fit their needs and drivethe results they want. A deeply multicultural organization,Capgemini has developed its own way of working, theCollaborative Business ExperienceTM, and draws on Rightshore ®,its worldwide delivery model.Rightshore® is a trademark belonging to Capgemini