Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Intro to Computer Science > Good Programming > Flashcards

Good Programming Flashcards

How to run tests and debug code. Exceptions and assertions

You may prefer our related Brainscape-certified flashcards:
Biology 101 flashcards
1
Q

Defensive Programming

A
  • Specifications for functions
  • Modularize programs
  • Check conditions on input/outputs (assertions)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Testing/validation

A
  • Compare input/output to specs
  • It’s not working!
  • How can I break my program?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Debugging

A
  • Study events leading up to the error
  • Why is it not working?
  • How can I fix my program?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Set yourself up for testing/debugging

A
  • design code to ease this part
  • break programs into modules that can be tested and debugged individually
  • document assumptions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Ready to test?

A 
Ensure code runs
- remove syntax errors
- remove static semantic errors
- Python Interpreter can usually find these
Set of Expected results
- and input set
- for each input a corresponding output
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Classes of tests

A
  • Unit testing
  • Regression testing
  • Integrations testing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Unit testing

A
  • validate each piece of the program

- testing each function separately

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Regression testing

A
  • add test for bugs as you find them in a function

- catch reintroduced errors that were previously fixed

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Integration testing

A
  • does overall program work?

- tend to rush to do this

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Testing methods

A
  • Intuition
  • Random testing
  • Black Box Testing
  • Glass Box Testing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Intuition

A

Pick natural boundaries to the problem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Random testing

A

If no natural partitions

  • Probability that code is correct increases with more test
  • Better options with Black Box and Glass Box
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Black Box Testing

A

Explore paths through specifications

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Glass Box Testing

A

Explore paths through code

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

More about Black Box testing

A
  • Designed without looking at the code
  • Avoid biases implementations
  • Testing can be reused
    Paths through specification
  • build test cases in different natural space partitions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Considerations for Black Box testing

A
  • empty lists
  • singleton lists
  • large numbers
  • small numbers
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

More about Glass Box testing

A
  • Use code directly to guide design of test cases

- Called path-complete if every potential path through code is tested at least once

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Drawback for Glass Box testing

A
  • can go through loops arbitrary many times

- missing paths

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Guidelines for Glass Box testing

A 
Branches
- exercise all parts of a conditional
for loops
- loop not entered
- body of loop executed exactly once
- body of loop executed more than once
while loops
- same as for loops
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Runtime bugs

A
  • Overt
  • Covert
  • Persistent
  • Intermittent
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Overt

A
  • Has an obvious manifestation

- Code crashes or runs forever

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Covert

A
  • Has no obvious manifestation

- Code returns a value, which may be incorrect but hard to determine

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Persistent

A
  • Occurs every time code is run
24
Q

Intermittent

A
  • Only occurs some times

- even if run on same input

25
Q

Overt and Persistent

A
  • Obvious to detect

- Use defensive programming to try to ensure that if error is made, bug will fall into this category

26
Q

Overt and Intermittent

A
  • More frustrating
  • Can be harder to debug
  • If condition that prompt bug can be reproduced -> can be handled
27
Q

Covert

A
  • Highly dangerous

- users may not realize answers are incorrect until code has been run for a long period

28
Q

Debugging Tools

A
  • Built in the IDE or code editor
  • Python Tutor
  • print statement
  • use your brain -> be systematic
29
Q

Print statements

A
  • Test hypothesis

- Bisection method

30
Q

When to Print

A
  • Enter function
  • Parameter
  • Function result
31
Q

Print using Bisection method

A
  • Put print halfway in code

- Decide where bug may be depending on value

32
Q

Logic errors

A
  • Think before writing new code
  • Draw picture - take a break
  • Explain the code to (someone else or a rubber duck)
33
Q

Debugging steps

A
  • Study program code

- Scientific method

34
Q

Debugging using study method

A
  • how did I get the unexpected result
  • dont’ ask what is wrong
  • is it part of a family
35
Q

Debugging using scientific method

A
  • study available data
  • form hypothesis
  • repeatable experiments
  • pick simplest input to test with
36
Q

Testing does

A
  • Write a function
  • Test the function, debug the function
  • Write a function
  • Test the function, debug the function
  • ** Do integration testing **
37
Q

Debugging does

A
  • Backup code
  • Change code
  • Write down potential bug in a comment
  • Test code
  • Compare new and old versions
38
Q

Debugging skills

A 
Treat as a search problem
Looking for explanation for incorrect behavior
- Study available data
- Form hypothesis
- Design and run a repeatable experiment
- Keep record of experiments performed
39
Q

Debugging as search

A
  • narrow down space of possible source of error
  • design experiments that expose intermediate stages of computation
  • use print statements
  • use results to further narrow search
  • binary search is a powerful tool
40
Q

Pragmatic hints for debugging

A
  • look for usual suspects
  • ask why the code is doing what it is
  • the bug is probably not where you think it is
  • don’t believe the documentation
  • take a break
41
Q

Exceptions

A

When a procedure execution hits an unexpected conditions

42
Q

IndexError

A

Trying to access beyond lists limits

43
Q

TypeError

A

Trying to convert an inappropriate type

Mixing data types without coercion

44
Q

NameError

A

Referencing a non-existing variable

45
Q

ZeroDivisionError

A

Trying to divide with 0

46
Q

ValueError

A

Operand type okay, but value is illegal

47
Q

IOError

A

IO system reports malfunction (eg. file not found)

48
Q

AttributeError

A

Local or global name not found

49
Q

What to do with Exceptions

A
  • Fail silently -> bad idea!
  • Return an “error” value -> what value to choose, complicates code
  • Stop execution, signal error condition -> raise an exception
50
Q

Dealing with exceptions

A
  • exceptions raised by any statement of try

- handled by the except and execution continues after the except statement

51
Q

Handling specific exceptions

A

Have separate except clauses to deal with particular type of exception

52
Q

Other exceptions

A
  • else -> is executed when execution of try body completes with no exceptions
  • finally -> always executed after: try, else and except clauses.
  • finally is executed even if they raised another error or executed a break, continue or return
  • finally is useful for clean-up code that should be run no matter what else happened
53
Q

Exceptions as control flow

A
  • Raise an exception when unable to produce a result consistent with functions specification
54
Q

Assertions

A
  • Use assert statement to raise an AssertaionError

- An example of good defensive programming

55
Q

Assertions as defensive programming

A
  • Don’t allow a programmer to control response from to unexpected conditions
  • Ensure the execution halts
  • Typically used to check inputs to functions
  • Can be used to check outputs of a function
  • Can make it easier to locate a source of a bug
56
Q

Where to use assertions

A
  • Goal to spot bugs
  • Supplement to testing
  • Raise exceptions if bad data is inputted
  • Check types
  • Check that in-variants on data structures are met
  • Check constraints on return value
  • Check for violations of constraints on procedure (e.g. no duplicates in a list)

Intro to Computer Science (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions