3 added 182 characters in body
source | link

The answer is simple, the execution is complex.

Basically what you're trying to do is isolateidentify the point at which the variance occurs i.e. the point at which the actual result starts to move away from the expected result (and if this sounds like something that might show up through coded tests ("unit" and up) then that's not entirely surprising). Similarly you need to identify the point at which the variance stops i.e. where do the paths join such that you've got a result that changes consistently again. Having identified those points you can work to further narrow down the possible locations for the "errors".

The brute force way is adding debug/trace statements, breakpoints and inspection and then running the code.

You improve on this in two ways:

  • First by reducing the amount of code you have to run - there are diverse means. (As suggested, this means isolating/separating out the problematic code.)
  • Second by wrapping the stuff in tests (which is probably the best of the diverse means if feasible).

Sadly none of this is straightforward or necessarily quick.

The answer is simple, the execution is complex.

Basically what you're trying to do is isolate the point at which the variance occurs i.e. the point at which the actual result starts to move away from the expected result (and if this sounds like something that might show up through coded tests ("unit" and up) then that's not entirely surprising). Similarly you need to identify the point at which the variance stops i.e. where do the paths join such that you've got a result that changes consistently again.

The brute force way is adding debug/trace statements, breakpoints and inspection and then running the code.

You improve on this in two ways:

  • First by reducing the amount of code you have to run - there are diverse means.
  • Second by wrapping the stuff in tests (which is probably the best of the diverse means if feasible).

Sadly none of this is straightforward or necessarily quick.

The answer is simple, the execution is complex.

Basically what you're trying to do is identify the point at which the variance occurs i.e. the point at which the actual result starts to move away from the expected result (and if this sounds like something that might show up through coded tests ("unit" and up) then that's not entirely surprising). Similarly you need to identify the point at which the variance stops i.e. where do the paths join such that you've got a result that changes consistently again. Having identified those points you can work to further narrow down the possible locations for the "errors".

The brute force way is adding debug/trace statements, breakpoints and inspection and then running the code.

You improve on this in two ways:

  • First by reducing the amount of code you have to run - there are diverse means. (As suggested, this means isolating/separating out the problematic code.)
  • Second by wrapping the stuff in tests (which is probably the best of the diverse means if feasible).

Sadly none of this is straightforward or necessarily quick.

2 Add point about looking for the end of the variation as well as the start
source | link

The answer is simple, the execution is complex.

Basically what you're trying to do is isolate the point at which the variance occurs i.e. the point at which the actual result starts to move away from the expected result (and if this sounds like something that might show up through coded tests ("unit" and up) then that's not entirely surprising). Similarly you need to identify the point at which the variance stops i.e. where do the paths join such that you've got a result that changes consistently again.

The brute force way is adding debug/trace statements, breakpoints and inspection and then running the code.

You improve on this in two ways:

  • First by reducing the amount of code you have to run - there are diverse means.
  • Second by wrapping the stuff in tests (which is probably the best of the diverse means if feasible).

Sadly none of this is straightforward or necessarily quick.

The answer is simple, the execution is complex.

Basically what you're trying to do is isolate the point at which the variance occurs i.e. the point at which the actual result starts to move away from the expected result (and if this sounds like something that might show up through coded tests ("unit" and up) then that's not entirely surprising).

The brute force way is adding debug/trace statements, breakpoints and inspection and then running the code.

You improve on this in two ways:

  • First by reducing the amount of code you have to run - there are diverse means.
  • Second by wrapping the stuff in tests (which is probably the best of the diverse means if feasible).

Sadly none of this is straightforward or necessarily quick.

The answer is simple, the execution is complex.

Basically what you're trying to do is isolate the point at which the variance occurs i.e. the point at which the actual result starts to move away from the expected result (and if this sounds like something that might show up through coded tests ("unit" and up) then that's not entirely surprising). Similarly you need to identify the point at which the variance stops i.e. where do the paths join such that you've got a result that changes consistently again.

The brute force way is adding debug/trace statements, breakpoints and inspection and then running the code.

You improve on this in two ways:

  • First by reducing the amount of code you have to run - there are diverse means.
  • Second by wrapping the stuff in tests (which is probably the best of the diverse means if feasible).

Sadly none of this is straightforward or necessarily quick.

1
source | link

The answer is simple, the execution is complex.

Basically what you're trying to do is isolate the point at which the variance occurs i.e. the point at which the actual result starts to move away from the expected result (and if this sounds like something that might show up through coded tests ("unit" and up) then that's not entirely surprising).

The brute force way is adding debug/trace statements, breakpoints and inspection and then running the code.

You improve on this in two ways:

  • First by reducing the amount of code you have to run - there are diverse means.
  • Second by wrapping the stuff in tests (which is probably the best of the diverse means if feasible).

Sadly none of this is straightforward or necessarily quick.