lecture 5: testing

38
LECTURE 5: TESTING CSC 213 – Large Scale Programming

Upload: eyal

Post on 15-Feb-2016

58 views

Category:

Documents


0 download

DESCRIPTION

CSC 213 – Large Scale Programming. Lecture 5: Testing. CSC 213 – Large Scale Programming. Lecture 5: Testing. Today’s Goal. Understand why testing code is important Result of poor or no testing & embarrassment caused Learn basics of writing good suite of test cases - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Lecture 5: Testing

LECTURE 5:TESTING

CSC 213 – Large Scale Programming

Page 2: Lecture 5: Testing

LECTURE 5:TESTING

CSC 213 – Large Scale Programming

Page 3: Lecture 5: Testing

Today’s Goal

Understand why testing code is important Result of poor or no testing &

embarrassment caused Learn basics of writing good suite of

test cases What test cases should do (& should not

do) Managing test cases to find as many bugs

as possible Make debugging easier with clear, focused

tests Analyzing tests to not waste time on

useless ones Learn types of test cases that most

often used Useful and helpful ideas from coders in

real-world

Page 4: Lecture 5: Testing

Why Does Testing Matter?

Page 5: Lecture 5: Testing

Why Does Testing Matter?

Page 6: Lecture 5: Testing

Why Does Testing Matter?

Page 7: Lecture 5: Testing

Why Does Testing Matter?

Page 8: Lecture 5: Testing

Testing Drives Debugging

DOES IT WORK CORRECTLY?

WHO GETS TO DECIDE?

HOW DO THEY KNOW?

CAN YOU OFFER ANY PROOF?

Page 9: Lecture 5: Testing

Testing Drives Debugging

DOES IT WORK CORRECTLY?

CAN YOU OFFER ANY PROOF?

Page 10: Lecture 5: Testing

Does It Work Correctly?

You have two options with all of this testing:1. Show code works by writing working tests2. Stop complaining & accept your

punishment

Page 11: Lecture 5: Testing

Does It Work Correctly?

You have two options with all of this testing:1. Show code works by writing working tests2. Stop complaining & accept your

punishment

Page 12: Lecture 5: Testing

What Is “Correct”?

Could check code against design being used Verification is name for these checks These tests are easy to create

Verification still assumes design is correct Validation checks code does what it should

Page 13: Lecture 5: Testing

What Is “Correct”?

All roads lead back to requirements

Page 14: Lecture 5: Testing

What Is The Error?

Make sure each test method looks for 1 error Easier debugging when you also use good

names Can you figure out when each of these

tests fail?testAverageOnNullArray()

testInsertFirstWhenEmpty()

testPopOnEmptyStack()

testOnTimeUsingTim()

testDeposit2()

Page 15: Lecture 5: Testing

Critical Property of Test

At start, test must FAIL

Page 16: Lecture 5: Testing

Critical Property of Test

At start, test must FAIL

Page 17: Lecture 5: Testing

Critical Property of Test

At start, test must FAIL

Page 18: Lecture 5: Testing

Could We Find an Error?

Write tests with known, constant answers Use constants in your assert* statements Relying on other methods’ results

propagate errors Which would you want, if your money’s

at stake?assertEquals(cut.addTwo(10), cut.addOne(11));assertEquals(cut.addTwo(10), 12);

assertEquals(cut.winner(), cut.runners[0]);assertEquals(cut.winner(), cut.getRunner(0));assertEquals(cut.winner(), “Cheetah”);

Page 19: Lecture 5: Testing

Are We Sure There Is No Error? Test all aspects of results to look for

any errors Should begin by looking that data returned

correct Check any fields and see if they are what is

expected Add assertions that array entries & other

data okay Problems caused when assume without full

data

Page 20: Lecture 5: Testing

Are We Sure There Is No Error? Test all aspects of results to look for

any errors Should begin by looking that data returned

correct Check any fields and see if they are what is

expected Add assertions that array entries & other

data okay Problems caused when assume without full

data

Page 21: Lecture 5: Testing

Where Is The Error?

Check methods from simplest to most complex Check easiest methods first and get them

working Once this done, test methods calling the

easiest ones Most complex methods tested last after all

else works Fixes method with bug & prevents

wasting time ONLY call method being tested to also help

with this

Page 22: Lecture 5: Testing

Why Is This An Error?

Always check your test cases Test cases are not perfect; may have errors Many hours lost looking for non-existent

bugs But, at the same time, bad test cases lame

excuse

Page 23: Lecture 5: Testing

How To Write Tests

Cannot prove there are no bugs Only ever show no bugs exist on those

tests Unlikely & boundary scenarios are vital

to test

Page 24: Lecture 5: Testing

How To Write Tests

Cannot prove there are no bugs Only ever show no bugs exist on those

tests Unlikely & boundary scenarios are vital

to test Keep in mind why Willie Sutton robbed

banksThat’s

where the money is

Page 25: Lecture 5: Testing

How To Test Boundaries

Each test should provide additional information Why write two tests which expose same

bug? Before writing test ask: what error will this

expose? Must Include boundary checks for

objects – null Test each parameter unless pre-condition

says no Good set of tests should also check all

fields used Boundaries for arrays & Strings also

very simple Unless forbidden, should also check if these null

Lengths of 0, 1, & n also important to try

Page 26: Lecture 5: Testing

Interesting Boundary Cases

Number are much harder; no simple rules exist To find boundaries, must look at variables

used Try negative, 0, & 1 when used in

arithmetic Check values around limit in if(…)

statementspublic int gcd(int ap, int a, int b) {if (b == 7) { return ap; }ap = a;a = b;b = ap % a;return gcd(ap, a, b);

}

Page 27: Lecture 5: Testing

Types of Loops

Simple Loop

ConcatenatedLoops Unstructured

Loops

Nested Loops

Page 28: Lecture 5: Testing

Types of Loops

Simple Loop

ConcatenatedLoops Unstructured

Loops

Nested Loops

Page 29: Lecture 5: Testing

Simple Loop

For all simple loops, try inputs that: Skip loop entirely Make 1 pass through the loop Make 2 passes through the loop Make m passes through the loop, where (m

> 2) If loop executed at most n times, try

inputs that: Make n-1, n, & (n+1) passes through the

loop

Page 30: Lecture 5: Testing

Types of Loops

Simple Loop

ConcatenatedLoops Unstructured

Loops

Nested Loops

Page 31: Lecture 5: Testing

Nested Loops

First test set runs all outer loops exactly once Inner loop runs (min+1), average, (max-1) & max times

Then run all but two innermost loops exactly once Inner loops run (min+1), average, (max-1) & max times

Tests should continue growing loop-by-loop

Page 32: Lecture 5: Testing

Types of Loops

Simple Loop

ConcatenatedLoops Unstructured

Loops

Nested Loops

Page 33: Lecture 5: Testing

Concatenated Loops

If loops are entirely independent No conditions, variables, or values in

common Woo-hoo! Just perform single loop tests on

each Otherwise treat as nested loops & make

life easier Work as if the first loop is outermost loops

Page 34: Lecture 5: Testing

Types of Loops

Page 35: Lecture 5: Testing

Unstructured Loops

Figure out the process leading to this decision Burn the artifacts creating this

abomination Anyone involved should terminated

immediately

Page 36: Lecture 5: Testing

Unstructured Loops

Figure out the process leading to this decision Burn the artifacts creating this

abomination Anyone involved should terminated

immediately

Page 37: Lecture 5: Testing

Unstructured Loops

Figure out the process leading to this decision Burn the artifacts creating this

abomination Anyone involved should terminated

immediately Rewrite “missing” documents from

scratch

Page 38: Lecture 5: Testing

For Next Lecture

Next weekly assignment available on Angel Due as usual on Tuesday at 5PM Use virtual extensions to delay this due

date

Reading on advanced testing techniques Does un-testable code exist? What do we do with this flaky, scary code? What tricks are there to help us work with

it?