Re: Coding inside the debugger
From: Phlip (phlip_cpp_at_yahoo.com)
Date: 08/23/04
- Next message: Isaac Gouy: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- Previous message: Matt: "Re: Workflow management"
- In reply to: Thomas Gagne: "Re: Coding inside the debugger"
- Next in thread: Victor: "Re: Coding inside the debugger"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 23 Aug 2004 05:00:42 GMT
Thomas Gagne wrote:
> Phlip wrote:
> > Thomas Gagne wrote:
> >
> >
> <snip>
> >
> >
> > Why the heck not? TDD leads to very aggressive decoupling, so those
details
> > are separate and exposed to tests.
> >
> How would a unit test inspect the state of a temporary variable?
By detemporalizing it?
> I don't disagree with that, but eventually you do write code, don't you?
> After you're finished writing a unit test (which itself is code) you
> eventually write some program code, right? Have you ever tried doing that
> inside the debugger? It's fun! Or at least I think it is.
Unit tests are an excellent platform for using a debugger.
I TDD, these days, on two platforms. One uses C++, WTL, COM, MSXML, and
Sanskrit. The other uses Ruby, REXML, GraphViz, and TkCanvas.
The VC++ platform has a full-featured integrated debugger on which I have
>10 years experience, and I use it freely. The Ruby platform I'm certain has
a debugger, but I have not yet once in my life ever used it, and I never
will. I edit Ruby using Scite, which supports simple edit commands the same
as VC++, and can execute the current script on <F5>.
My velocity, and defect rates, in both platforms, are comparable.
Without a debugger, one uses trace statements. My VC++ trace statement is
the most sophisticated one in this industry:
#define db(x_) do { std::stringstream z; \
z << __FILE__ << "(" << __LINE__ << ") : " \
#x_ " = " << x_ << endl; \
cout << z.str() << std::flush; \
OutputDebugStringA(z.str().c_str()); \
} while (false)
That takes any argument, including expressions, which support operator<<,
and it reflects that source's expression using the # stringerizer operator.
db(q) pushes "C:\path\source.cpp(99) : q = 5\n" into the Output Debug panel.
<F8> parses the file name and line number and navigates your editor directly
to the line containing the db(q). Put another way, my trace statements can n
avigate my editor directly to their source.
Amazingly, when I perform light debugging of a sticky situation in Ruby, I
have not yet bothered to put my equivalent trace statement online for my
current project. My Ruby trace statement attempts the same things as my C++
one:
def trace_(&b)
file, line_nr, funkshun = caller()[0].split(':')
funkshun = funkshun.split('in `')[1]
funkshun = funkshun.split("'")[0]
line_nr=line_nr.to_i
linecnt=1
expr=nil
File.open(file).each_line do |line|
if linecnt==line_nr
if line =~ '(^|\W)trace_\s*{\s*(.*?)\s*}'
expr = $2
end
break
end
linecnt+=1
end
if expr
puts "(#{line_nr})#{funkshun} #{expr}: #{eval(expr,
b).inspect}"
end #{file}
end
It attempts to reflect its source into its output, like db() did.
But I have not used that in years. Nowadays, I debug my Ruby using its
built-in method p(), which is Ruby's debugging statement. And for
Intellisense, I have a little jigger that prints out all of an object's
non-standard public methods:
def doc(anObject)
puts(anObject.class.name)
itsMethods = anObject.public_methods() -
Object.new().public_methods()
puts(itsMethods.sort()) if !itsMethods.nil?
end
That works great for learning about the methods of some ornery undocumented
object that wraps an object written in some dead language.
TDD doesn't prevent debugging. It prevents, as a powerful emergent force,
those long open-ended multi-week bug hunts that destroyed schedules so
reliably.
-- Phlip http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
- Next message: Isaac Gouy: "Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management"
- Previous message: Matt: "Re: Workflow management"
- In reply to: Thomas Gagne: "Re: Coding inside the debugger"
- Next in thread: Victor: "Re: Coding inside the debugger"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
