An Overview of automated testing (1)
- 1. An Overview of the automated testing And the forgotten level of the testing pyramid
- 2. Why is a programmer talking about tests?
- 3. Pros vs Cons Why? Is it worth it ?
- 4. Whyshould anyone write automated tests? One should write an automated test … • … to achieve a good design. • … to clarify how the system works. • … to understand the system. • … to minimize risks. • … to test a system.
- 5. Is it worth it? Automatize tests require… • … time to write. • … time to adjust, fix and maintain. • … time to setup/execute.
- 6. How to minimize the efforts? Writing tests that... • ... are easy to run. • … are easy to write. • … require minimal maintenance.
- 7. Case scenario MD5? OCR? Don't overestimate assertion over output!!! Name: Hannah Date: 14th September Feature: “Loves her cat Pebbles” How to test?
- 8. Gathering information "Truth can only be found in one place: the code." — Robert C. Martin, Clean Code Unit Test • What the developer wants Acceptance Test • What the customer wants Code • What the program does
- 10. What developers want • There are two main issues that concern the programmer: • The complexity • The risk
- 11. Dealing with complexity There is only one way to deal with complexity: avoiding it, usually by abstraction • Separation of concerns • High level of abstraction →Wishful thinking: “imagine there is a function that solves the problem…”
- 12. TDD and Abstraction • Describe our intentions before we write how (single responsibility) • Minimize the number of collaborators. • Minimize the scope.
- 14. Unit Tests Limitations - if the units work well in isolation, we do not know if they work well together. - Unit tests rely on doubles (specially mocks and stubs). There is a sane level of usage for mocks!!!
- 15. What the customer wants • What the customer wants ⇒ Acceptance test • Acceptance test ⇒ definition of done + system documentation • Practical scenarios helps to identify ambiguous and contradictory requirements. • Acceptance tests focus on “real” user scenarios
- 16. Acceptance tests limitations • They are slow • They are fragile and sometimes not reliable. • They are not isolated • They are not very practical
- 17. Lost layer of Test pyramid ●Presentation Layer Test ●Service Layer Test ●Subcutaneous Test ●Persistence Layer Test
- 18. Layered testing
- 19. BONUS
- 20. Mocks overuse / pedantic unit test @Test public void testCreditCardIsCharged() { paymentProcessor = new PaymentProcessor(mockCreditCardServer); when(mockCreditCardServer.isServerAvailable()).thenReturn(true); when(mockCreditCardServer.beginTransaction()) .thenReturn(mockTransactionManager); when(mockTransactionManager.getTransaction()) .thenReturn(transaction); when(mockCreditCardServer.pay(transaction, creditCard, 500)) .thenReturn(mockPayment); when(mockPayment.isOverMaxBalance()).thenReturn(false); paymentProcessor .processPayment(creditCard, Money.ofMajor(CurrencyUnit.USD, 500)); verify(mockCreditCardServer).pay(transaction, creditCard, 500); }