21
Test Driven Development Designing Test Cases Haarlem Software Developer Meetup

Designing Test Cases (Test Driven Development)

Embed Size (px)

Citation preview

Page 1: Designing Test Cases (Test Driven Development)

Test Driven DevelopmentDesigning Test Cases

Haarlem Software Developer Meetup

Page 2: Designing Test Cases (Test Driven Development)

Confidential Page 2

KvK 53479335

Lichtfabriekplein 1, 2031 TE Haarlem

P.O. Box 2031 , 2002 CA Haarlem

+31 (0)88 248 1632, [email protected]

www.ximedes.com

Confidential Page 2

Meetup Sponsor:

Page 3: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 3

Page 4: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 4

Page 5: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 5

Why do we test?Why do we automate tests?What are good tests?

Page 6: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 6Build Confidence and Create Trust

Why do we have tests?

Page 7: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 7

Why do we automate tests?

Page 8: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 8

What are good tests?

http://stackoverflow.com/questions/61400/what-makes-a-good-unit-test

Page 9: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 9

Intent:

Tests should express what we expect the code to do. Tests should be readable.

Page 10: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 10

Independent

The success ot failure of a test should not depend on anything other then the production code.

The order of the tests. The system running the tests.

Page 11: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 11

Repeatable

Tests should produce the same results each time..every time.Tests should not rely on uncontrollable params.

Page 12: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 12

Clean Code

SRP: Each test should test just one thing DRY: Any given behavior should specified in

one and only one test NAME: Tests should have proper names. Tests should not have side effect

Single Responsibility PrincipleDon’t Repeat Yourself

Page 13: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 13

1. Arrange2. Act3. Assert

Page 14: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 14

Page 15: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 15

Given the numbers 3 and 4When I multiply those numberThen the result should be 12

Given the numbers 6 and 8When I multiply those numberThen the result should be 48

Specification by Example

Page 16: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 16

Use ‘personas’ express expectations

Page 17: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 17

Arrange:Given Joris is a member of the HSDM

Act:When Marco publishes a newly scheduled Meetup

Assert:Then Joris should receive a Notification about the event

Page 18: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 18

1. You are here to LEARN. (and have fun)

2. Try to do your best.

3. Work in pairs.Find a partner in a similar programming language and operating system

Page 19: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 19

Write a system to help the umpire keep track of the score of a single Game.

The umpire inputs which player won a pointThe systems output is: The current score within the game.

Example:• Player one scores a point Score: 15-0• Player one scores a point Score: 30-0• Player two scores a point Score: 30-15

Page 20: Designing Test Cases (Test Driven Development)

01-10-2015 Confidential Page 20

A game is won by the first player to have won at least four points in total and at least two points more than the opponent. The score is then “Win for player1” or “Win for player2”

The running score of each game is described in a manner peculiar to tennis: scores from zero to three points are described as “Love”, “Fifteen”, “Thirty”, and “Forty” respectively.

If at least three points have been scored by each player, and the scores are equal, the score is “Deuce”.

If at least three points have been scored by each side and a player has one more point than his opponent, the score of the game is “Advantage player1” or “Advantage player2”.

Page 21: Designing Test Cases (Test Driven Development)

See you next time: February 16thTest Driven Development

Designing Testable (Clean) code Haarlem Software Developer Meetup