1.
Tratto da una storia vera…
A QA engineer walks into a bar. Orders a beer.
Orders 0 beers. Orders 99999999999 beers.
Orders a lizard. Orders -1 beers. Orders a
ueicbksjdhd.
First real customer walks in and asks where the
bathroom is. The bar bursts into flames, killing
everyone.

2.
Stefano Ottaviani
Software Engineer
@Ste8
stefano@smartmobile.it
steott@gmail.com
About Me

3.
About You
•Chi è
• Sviluppatore
• Tester
• Project Manager / Imprenditore / …
• Altro
•Chi scrive già test automatici?
•Chi sa cosa sono i test automatici?
•Chi non sa cosa sono?

4.
About Your Company
Come considera la scrittura di test automatici?
•Ignora l’esistenza dell’argomento
•Importanti al pari (o più) dello sviluppo
•Meno dello sviluppo, ma comunque importanti
•Superflui
•Dannosi

5.
WHO?

6.
Illustrations by Lisa Dzera
TesterDeveloper User

7.
“A first major mistake
people make is thinking
that the testing team is
responsible for assuring
quality”
–Brian Marick
Developer, Tester e Utenti:
i Developer sono i primi a poter
accorgersi dei problemi e a poterli
correggere

8.
WHY?

9.
SOFTWARE
SOFTWARE EVERYWHERE
SOFTWARE
SOFTWARE EVERYWHERE

10.
BOKEN SOFTWARE EVERYWHEREBOKEN SOFTWARE EVERYWHERE
BROKEN SOFTWAREBROKEN SOFTWARE

11.
Altra storia… vera!

12.
…spot the bug!
for (
var referenceDay = startDay;
referenceDay < endDay;
referenceDay = referenceDay.AddDays(1))
{
}

13.
…e altri benefici!
Requisiti male interpretati

14.
WHAT?

15.
Tipi di test
• Unit testing
• Integration testing
• End-to-end testing / UI Testing
• Functional testing
• API testing
• Property Based Testing
• Mutation testing
• Smoke testing
• Acceptance testing
• Performance Testing
• Load testing
• Stress testing
• Security testing
• Usability testing
• Accessibility testing
• …

16.
Tipi di test
• Unit testing
• Integration testing
• End-to-end testing / UI Testing
• Functional testing
• API testing
• Property Based Testing
• Mutation testing
• Smoke testing
• Acceptance testing
• Performance Testing
• Load testing
• Stress testing
• Security testing
• Usability testing
• Accessibility testing
• …

17.
Metodologie
• TDD (Test Driven Development)
=> Red / Green / Refactor
• BDD (Behavior Driven Development)
=> Given / When / Then
• Test First
• ….

18.
Metodologie
• TDD (Test Driven Development)
=> Red / Green / Refactor
• BDD (Behavior Driven Development)
=> Given / When / Then
• Test First
• ….

19.
Definizione di Unit Test (1/2)
A unit test is an automated piece of code
that invokes a unit of work in the system and
then checks a single assumption about the
behavior of that unit of work.
http://artofunittesting.com/definition-of-a-unit-test/

20.
Definizione di Unit Test (2/2)
A unit of work is a single logical functional
use case in the system that can be invoked
by some public interface (in most cases). A
unit of work can span a single method, a
whole class or multiple classes working
together to achieve one single logical
purpose that can be verified.
http://artofunittesting.com/definition-of-a-unit-test/

21.
Un buon Unit Test: (1/2)
1.Able to be fully automated
2.Has full control over all the pieces running
(Use mocks or stubs to achieve this isolation when needed)
3.Can be run in any order if part of many other tests
4.Runs in memory
(no DB or File access, for example)
5.Consistently returns the same result
(You always run the same test, so no random numbers, for
example. Save those for integration or range tests)

22.
Un buon Unit Test: (2/2)
6.Runs fast
7.Tests a single logical concept in the system
8.Readable
9.Maintainable
10.Trustworthy
(when you see its result, you don’t need to debug the
code just to be sure)

23.
VS
Tester knows about internals and
exploit that knowledge
Based on code analysis
•Statement coverage
•Branch coverage
•Condition coverage
•Basis path coverage
=> Cyclomatic complexity
Tester does not know anything about
the test object internal
Focuses on functional requirements
Based on input domain analysis
- Equivalence partitioning
- Boundary value analysis

24.
Integration Test
• Usano una o più dipendenze “reali” del sistema testato
• real System Time (e.g. DateTime.Now),
• real File System
• real Database
• real Web Services
• Non veloci come gli Unit Test
• Non consistenti, possono ritornare valori diversi a
causa delle loro dipendenze (es. dal System Time)

25.
Test End-to-End
Ensure that the integrated components of an application function as
expected. The entire application is tested in a real-world scenario such
as communicating with the database, network, hardware and other
applications.
For example, a simplified end-to-end testing of an email application might
involve:
• Logging in to the application
• Accessing the inbox
• Opening and closing the mailbox
• Composing, forwarding or replying to email
• Checking the sent items
• Logging out of the application

26.
HOW?

27.
String Calculator
KATA (by Roy Osherove)

28.
“1,2” => 3
“1,3,4” => 8

29.
1° step
Create a simple String calculator with a method int Add(string numbers)
1. The method can take 0, 1 or 2 numbers, and will return their sum (for an
empty string it will return 0) for example “” or “1” or “1,2”
2. Start with the simplest test case of an empty string and move to 1 and two
numbers
3. Remember to solve things as simply as possible so that you force yourself
to write tests you did not think about
4. Remember to refactor after each passing test

30.
2° step
Allow the Add method to handle
an unknown amount of numbers.

31.
3° step
Allow the Add method to handle new lines between numbers
(instead of commas).
the following input is ok: "1n2,3" (will equal 6)
the following input is NOT ok: "1,n" (not need to prove it - just
clarifying)

32.
4° step
Support different delimiters
1. to change a delimiter, the beginning of the string will contain
a separate line that looks like this: “//[delimiter]
n[numbers…]” for example “//;n1;2” should return 3 where
the default delimiter is ‘;’ .
2. the first line is optional. all existing scenarios should still be
supported

33.
5° step
Calling Add with a negative number will throw an exception
“negatives not allowed” - and the negative that was passed.
If there are multiple negatives, show all of them in the exception
message.

34.
6° step
Continua su
https://osherove.com/tdd-kata-1

35.
PRICE Calculator
KATA

36.
RECAP!

37.
1. Individuazione Bug

38.
2. Sviluppo più veloce
senza andare in debug

39.
3. Sviluppo più veloce senza dipendere dai
tempi di riposta dei sistemi esterni
(database, webservice, …)

40.
4. Non dover attendere lo sviluppo di
dipendenze esterne
(database, webservice, …)

41.
5. Suite di test di regressione

42.
6. Feedback rapido e “visivo”

43.
7. Refactoring

44.
8. Scervellarsi di meno con le
“Boundary conditions”

45.
9. Miglior design del codice
(modularizzazione, coupling,
Single Responsibility Principle, …)

46.
10. Aiuto nelle Code Review

47.
11. Evitare il “blocco dello scrittore”
(specialmente con TDD)

48.
12. Mettersi nei “panni” degli
utilizzatori delle nostre API

49.
13. Continuous Integration

50.
14. Test utilizzabili come
esempi e documentazione

51.
15. Confidenza

52.
16. Qualche volta una gioia!

53.
“Testing shows the presence,
not the absence of bugs.”
–Edsger W. Dijkstra
… ma ricordando che:

54.
WHEN?

55.
WHERE?

56.
DOMANDE?