This document discusses automated testing and different levels of testing. It explains that automated tests should be written to achieve good design, clarify how a system works, understand the system, and minimize risks. While automated tests require time to write, maintain, and execute, these efforts can be minimized by making tests easy to run and maintain with minimal dependencies. The document also discusses different perspectives on testing, including what developers and customers want. Developers are concerned with complexity and risk, while customers care about functionality and user scenarios. It notes that while unit tests have limitations, acceptance tests are also limited as they are slow, fragile, and not isolated. The "lost layer" of the testing pyramid is also mentioned - the presentation, service, and persistence

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

9. Different perspectives

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.

13. Additional goodies

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);
}

21. Questions?
Rodrigo di Lorenzo Lopes
rdllopes@gmail.com