A Tool for debug robot testcase step by step

[GoogleCodeExporter]

What is the expected output? What do you see instead?
1. A Debugger window can track the testcase step by step.
2. add "--debug gui" on pybot command line, the pybot runinto a debug mode.
And a Debuger window will pop-up.

Please provide any additional information below.
The patch for robot coding.

C:\USERS\_work\robotframework-read-only\src\robot>svn di
Index: conf/settings.py
===================================================================
--- conf/settings.py    (revision 369)
+++ conf/settings.py    (working copy)
@@ -55,7 +55,8 @@
                   'TagStatLink'      : ('tagstatlink', []),
                   'LogLevel'         : ('loglevel', 'INFO'),
                   'MonitorWidth'     : ('monitorwidth', 78),
-                  'MonitorColors'    : ('monitorcolors', 'ON') }
+                  'MonitorColors'    : ('monitorcolors', 'ON'),
+                  'DebugMode'        : ('debug', None) }

     _deprecated = { 'colormonitor'   : 'monitorcolors' }

Index: __init__.py
===================================================================
--- __init__.py (revision 369)
+++ __init__.py (working copy)
@@ -28,6 +28,7 @@
 from serializing import RobotTestOutput, RebotTestOutput, SplitIndexTestOutput
 from errors import DataError, INFO_PRINTED, DATA_ERROR, FRAMEWORK_ERROR
 from variables import init_global_variables
+from debuger import TestSuiteDebuger
 import utils

 __version__ = utils.version
@@ -80,6 +81,10 @@
     pybot --log mylog.html /path/to/tests.html /path/to/tests2.html
     """
     settings = RobotSettings(options)
+    debuger = None
+    if settings['DebugMode'] is not None:
+        debuger = TestSuiteDebuger(settings)
+        debuger.start()
     output = Output(settings)
     settings.report_errors(output.syslog)
     init_global_variables(settings, output.syslog)
@@ -98,6 +103,8 @@
             testoutput = RebotTestOutput(datasources, settings, output.syslog)
         testoutput.serialize(settings, output.syslog)
     output.close2()
+    if debuger is not None:
+        debuger.close()
     return suite

Index: runner.py
===================================================================
--- runner.py   (revision 369)
+++ runner.py   (working copy)
@@ -239,6 +239,7 @@
                           |  # This is a comment line
                           |  my_tests.html
                           |  path/to/test/directory/
+ -X --debug mode          Debug mode(remote, gui)
  -h -? --help             Print usage instructions.
  --version                Print version information.

-----
OTHER:
1. It's simply and ugly, because it major used to verify the feasibility of
idea.
2. About the debugger window:
    a. you can add some breakpoints in the testcase at the right plane of
debuger window.
        1. the breakpoints should a keyword name, and the wildcard is
supported. The testcase will stopped when it matched the breakpoint keyword
name. 
    b. the debuger tools:
        1. Run -- the testcase will run with no pause until a breakpoint is
mathced.
        2. Go into -- To execute a keyword, and stoped before next keyword
executing, track into if the next keyword is a userkeyword.
        3. Go over -- To execute a keyword, and stoped before next same
level keyword.
        4. Go Result -- To execute a keyword, and stoped before the current
keyword return.  (Used for watch the return result of current keyword,NOT
SUPPORTED in currently.) 
    c. the Varibles window will shoud the variabe name and value of current
keyword.
    d. The Console window will list all the executed keywords, and the last
one is the current paused keyword.
    e. The Call stack will list the caller relationship of userkeyword.

Original issue reported on code.google.com by Deo...@gmail.com on 7 Jul 2008 at 3:00

Attachments:

• debug_tools.zip
• screen.GIF

[GoogleCodeExporter]

I'm currently on holiday and don't have too much time to investigate this. 
After a
very quick look I can anyway tell at least three big reasons why the attached 
patch
won't be included in Robot Framework any time soon.

1) The GUI uses TKInter which is not available on Jython. 
2) No tests are included.
3) No good use case why debugger would be needed is given.

1&2 are just technical issues and they can, of course, be done if there's a big
enough need for this functionality. Most important thing is, however, 
discussing is
such a debugger needed in the first place, and can some existing functionality 
(e.g.
debugfile or listeners) be used instead. 

Original comment by lau...@gmail.com on 7 Jul 2008 at 8:21

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

yes. the debugfile and trace information can used in most of case. As i know, 
only
the IPS team have expectation about this feature. they wish the testcase can be
paused, and       check the external device status, when they debug a failed 
testcase. 

Original comment by Deo...@gmail.com on 8 Jul 2008 at 1:17

[GoogleCodeExporter]

add testcase and testsuit hooks in the attachement.

I think the RobteIDE should integrate a debug funcation. the debugfile and trace
information can't instead of this. of course, may haver other better solution.

Original comment by Deo...@gmail.com on 8 Jul 2008 at 1:27

Attachments:

• debuger.zip

[GoogleCodeExporter]

Reply to comment 2:

If the need is to pause test execution to investigate the status of the SUT, 
there
probably are easier approaches than implementing a separate debugger GUI. Two
possibilities that come to my mind are:

1) Use the listener interface so that the end_test method blocks until user 
action if
the test case status is FAIL.

2) Use a suitable keyword in test teardown to block the execution. It is 
possible to
use e.g. '${TEST_STATUS}' variable or 'Run Keyword If Test Failed' keyword.

Is there some reason these approaches would not work?

Reply to comment 3:

At least in the near future Robot IDE will be used only for generating test 
data.
Using it for also executing tests (which is a precondition for integrating it 
with
debugging) is quite complicated because it needed to a) support both Python and
Jython, b) support all same command line options and environment variables that 
can
be used currently, and c) probably also allow using Rebot somehow.

Original comment by lau...@gmail.com on 8 Jul 2008 at 10:12

[GoogleCodeExporter]

I really think using listener interface is the best approach for implementing 
this
kind of tool. In 2.0.2 we added new methods start_keyword and end_keyword 
(issue 100)
and made it possible to give arguments to listeners (issue 103), and these
enhancements ought to make it even easier to create a debugger. If the current
listener methods don't provide enough information, that can be fixed in issue 
88.

For more information about listeners see:
http://robotframework.googlecode.com/svn/trunk/doc/userguide/RobotFrameworkUserG
uide.html#using-listener-interface

Implementation suggested in this issue originally won't be implemented. Please 
open a
new issue for a tool using listeners interfaces for getting the debug 
information.
Note also that there's issue 101 that describes a related tool.

Original comment by pekka.klarck on 18 Nov 2008 at 3:46

• Changed state: WontFix