More advice from Alex:
alexey verkhovsky: typing
alexey verkhovsky: require 'breakpoint'; breakpoint
alexey verkhovsky: is too long
alexey verkhovsky: therefore, I usually have something like
alexey verkhovsky: def bp require 'breakpoint'; breakpoint; end
alexey verkhovsky: somewhere in the ap
alexey verkhovsky: this way, inserting a breakpoint is just bp
alexey verkhovsky: and it doesnt try to load brerakpoint.rb when it doesnt
need to
alexey verkhovsky: (it's quite long to load)
BTW, i also found out that
require 'breakpoint'
won't work in IRB.
At 06:44 PM 8/19/2005, Michael Kelly wrote:
Quoted from Alex Verhovsky:
there is this RubyForge project called 'breakpoint',
http://ruby-breakpoint.rubyforge.org/wiki/wiki.pl?HomePage, which opens
an IRB session inside a running Ruby program. With it, you can do
something like
test/watir/long_convoluted_test_script.rb
require 'watir'
include Watir
config = load_configuration
database = connect_to_database
ie = IE.start('http:/foo.bar.com/login')
ie.text_field(:id, 'username').set_value('me')
...
...
...
# somewhere in the middle
require 'breakpoint'
breakpoint
...
and this will execute the script until breakpoint and then open an IRB
session in which the actual values of ie, configuration, database are
available and even can be modified. As well as any other variable
visible from the breakpoint location. Exiting the IRB continues the
program.
This is often the easiest way to get to the state that you want to play
with. Besides, you can do conditional breakpoints
breakpoint if <some arbitrarily complex condition>
Bottom line: don't leave home without it.
Alex
_____________________
Bret Pettichord
www.pettichord.com
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
