software dev - midterm 2

method for debugging

1. stabilize the error

2. locate the source of the error

3. fix the defect

4. test the fix

5. look for similar errors

stabilize the error

• find a test case that reproduces the error each time executed

• vary the test case to recognize which factor influences the error and which ones do not

• simplify the test case to the smallest amount of factors, data, and functionality expected to produce the error

locate the source of the error

• brainstorm to produce a set of hypothesis

• create experiments, additional tests to obtain data to prove/disprove the hypothesis, and to locate the error

breakpoint

• intentional stopping or pausing place in your code, set within a debugging tool

• program executes normally until the breakpoint

• suspends execution before that line of code runs

refactoring

the process of restructuring existing code to make it easier to make it cleaner and more efficient without changing its external behavior

extract method

a specific refactoring method where you take a chunk of code from a long method and move it into its own, new method

strategy to recover what a method is doing

• identify what is used as input:

  • parameters

  • instance attributes/fields

  • static variables

• Identify what is the overall effect, output of a method call

  • Identify all exit points and their return values

  • instance attributes/fields

  • static variables

class interface

• a java interface that accompanies a class

• set of public methods of a class

add comments

• to clarify intent: what is code supposed to compute

• to summarize code at a higher level of abstractions:

  • gives guidance to the reader where to find a particular feature

Steps in building a method

• design the routine

• check the design

• code the routine

• review and test the code

benefits of pseudocode

• makes reviews easier

• supports the idea of iterative refinement

• makes changes easier (before coding)

• minimizes commenting effort

• easier to maintain than other forms of design documentation

pseudocode programming proccess

1. check prerequisites

2. name the method

3. decide how to test the method

4. check for existing solutions (reuse code, ideas)

5. consider error handling

6. consider efficiency (no premature optimzation)

7. check for existing data types, algorithms

8. think about the data (data types, what to store)

9. write/refine description in pseudocode

10. check/review pseudocode

coding: once you got the pseudocode

• write the routine declaration

• write the first and last statements, and turn the pseudocode into high level comments

• fill in the code below each comment

• check the code

• clean up leftovers

static analysis

• reads the code but never run sit

• it can see what kind of input you expect, but not the actual value

McCabe's Cyclomatic Complexity

• counts the total number of linearly independent paths through a program 

• a path is a unique route code can take from start to end

• a higher CC number means the code is more complex and has more branches

• PMD: number of decision points plus one for method entry

  • 11+ is very high complexity

NPathComplexity

• number of acyclic execution paths through that method

• it is multiplicative

• value >= 200: reduce complexity

ExcessiveMethodLength

• indicates that the method is doing too much

  • reduce method size by creating helper methods, remove cp&paste code

ExcessiveParameterList

• indicates that a new object should be created to wrap the numerous parameters, try to group the parameters together

ExcessiveClassLength

• indicates that the class may be trying to do too much

• try to break it down and reduce size to something more manageable

ExcessivePublicCount

large number of public methods/attributes indicates the class may need to be broken up to limit efforts for thoroughly testing it

TooManyFields

• too many fields could be redesigned to have fewer fields, passibly through some nested object grouping of some of the info

Findbugs: correctness bug

• an apparent coding mistake resulting in code that was not what the developer intended

• strive for a low false positive rate

Findbugs: bad practice

• violations of recommended and essential coding practice

• ex: hash code and equals problems, cloneable idiom, dropped exceptations, serializable problems, and misuse of finalize

Findbugs: dodgy

• code that is confusing, anomalous, or written in a way that leads itself to errors.

• ex: dead local stores, switch fall through, unconfirmed casts, and redundant null check of value known to be null

PMD: SwitchDensity

measures the concentration of case statements within a switch block

PMD: CognitiveComplexity

• adds a penalty for loops, conditionals, catch blocks, goto labels, break/continue to a label, and recursion

• adds an increasing penalty for nested structures

• use helper methods to fix

PMD: LawOfDemeter

• a method should only call methods on its own class, objects, or parameters

• chain of method calls is not ideal

test case

set in inputs, execution conditions + pass/fail criterion

unit testing

find errors by checking pieces (a single class, method) in isolation

integration testing

find errors by looking at pieces (classes, methods) when they work together

system testing

find errors when running the full system in its environment

regression testing

retest to see if code still works, passes tests it passed before changes were made

how errors are distributed across a code base

• 80% of errors are found in 20% of a project’s classes or routines

• 50% of the errors are found in 5% of a project’s classes

black box testing

• focus: public interface

• based on: sw requirements spec and interface docs

• unaware of implementation details

• particular strength: omission errors

• test code doesn’t depend on implementation

white box testing

• focus: source code

• based on: sw requirements, interface docs + code

• particular strength: can test complex pieces of code more rigorously

data can exist in 1 of 3 states

• defined: data initialized but not used yet

• used: data has been used for computation

• killed: data was once defined, but is undefined now

equivalence partioning

• partition parameter/value ranges into groups that would have the same effect

• for each group create only one test case with a representative value chosen from the equivalence set

error guessing

based on past experience, tester guesses what cases the implementation may not handle correctly

boundary analysis

check cases around limits and extreme cases

bad data test cases includes

• too little data

• too much data

• the wrong kind of data (invalid data)

• wrong size of data

• uninitialized data

good data test cases include

• nominal cases-middle of the roat, expected values

• minimum normal configuration

• maximum normal configuration

• compatibility with old data set

oracle

• the mechanism that provides the pass/fail criterion for a test case

• the source of truth that tells you what the correct, expected answer should be

control flow coverage criteria

• statement (node, block) coverage

• branch (edge) coverage

  • if/switch conditions

• condition coverage

  • each basic condition evaluated to true and false (A && B && C)

• path coverage (structured basis/cyclomatic testing)

  • execution paths through a method

• data flow (syntactic dependency) coverage

  • define-used pairs of data

• function coverage

Modified condition/decision coverage

• requires that each basic condition be shown to be independently affecting the outcome of each decision

• each variable must be shown to contain the power to flip the switch on its own, without help or interference from the others

• The Method: Hold everything else constant. Flip the one variable. Does the output flip?

  • Yes: It independently affects the outcome.

  • No: It is being masked by another variable (or the logic is flawed).

statement coverage

measures the percentage of executable statements in your code that have been run at least once during testing

branch coverage

measures the percentage of decision outcomes (branches) that have been executed

condition coverage

requires that each individual boolean condition in a decision statement evaluates to both True and false at least once