Back to marketplace

Good Programming

No description yet. This curated deck is ready for daily study.

Total cards: 24•Content version: v4•Public deck•Updated: 8/1/2026

Card preview (24)

#1
Front (Question)

Defensive Programming

Back (Answer)

• Specifications for functions • Modularize programs • Check conditions on input/outputs (assertions)

#2
Front (Question)

Testing/validation

Back (Answer)

• Compare input/output to specs • It’s not working! • How can I break my program?

#3
Front (Question)

Debugging

Back (Answer)

• Study events leading up to the error • Why is it not working? • How can I fix my program?

#4
Front (Question)

Set yourself up for testing/debugging

Back (Answer)

• design code to ease this part • break programs into modules that can be tested and debugged individually • document assumptions

#5
Front (Question)

Ready to test?

Back (Answer)

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

#6
Front (Question)

Classes of tests

Back (Answer)

• Unit testing • Regression testing • Integrations testing

#7
Front (Question)

Unit testing

Back (Answer)

• validate each piece of the program - testing each function separately

#8
Front (Question)

Regression testing

Back (Answer)

• add test for bugs as you find them in a function - catch reintroduced errors that were previously fixed

#9
Front (Question)

Integration testing

Back (Answer)

• does overall program work? - tend to rush to do this

#10
Front (Question)

Testing methods

Back (Answer)

• Intuition • Random testing • Black Box Testing • Glass Box Testing

#11
Front (Question)

Intuition

Back (Answer)

Pick natural boundaries to the problem

#12
Front (Question)

Random testing

Back (Answer)

If no natural partitions • Probability that code is correct increases with more test • Better options with Black Box and Glass Box

#13
Front (Question)

Black Box Testing

Back (Answer)

Explore paths through specifications

#14
Front (Question)

Glass Box Testing

Back (Answer)

Explore paths through code

#15
Front (Question)

More about Black Box testing

Back (Answer)

• Designed without looking at the code • Avoid biases implementations • Testing can be reused Paths through specification • build test cases in different natural space partitions

#16
Front (Question)

Considerations for Black Box testing

Back (Answer)

• empty lists • singleton lists • large numbers • small numbers

#17
Front (Question)

More about Glass Box testing

Back (Answer)

• Use code directly to guide design of test cases - Called path-complete if every potential path through code is tested at least once

#18
Front (Question)

Drawback for Glass Box testing

Back (Answer)

• can go through loops arbitrary many times - missing paths

#19
Front (Question)

Guidelines for Glass Box testing

Back (Answer)

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

#20
Front (Question)

Runtime bugs

Back (Answer)

• Overt • Covert • Persistent • Intermittent

#21
Front (Question)

Overt

Back (Answer)

• Has an obvious manifestation - Code crashes or runs forever

#22
Front (Question)

Covert

Back (Answer)

• Has no obvious manifestation - Code returns a value, which may be incorrect but hard to determine

#23
Front (Question)

Persistent

Back (Answer)

• Occurs every time code is run

#24
Front (Question)

Intermittent

Back (Answer)

• Only occurs some times - even if run on same input