RF GUI
Grompy
interface(Porfi) for robot framework here.
Features as of now:
**Only for HTML**
Uses Meta:Project to strip a project for every script added.
Organizes scripts based on projects.
Runs scripts for how ever many iterations the user defines.
Gracefully stops scripts finish current running script then post
process outputs.
Ability to define output paths for each individual project.
Menu options to set what outputs to create after running.
Text Ctrl for optional arguments to run for all scripts. Persistent
per project.
Edit Menu allows for deleting script from porfi, changing porfi data
per script, open script with ride button.
**Makes path for current project's lib directory, resource directory,
variable directory, and more.
Sends paths as variables to running scripts, along with current
running project
Possible Future Features:
Brutal stop script essentially a ctrl+c to the running script
Optional arguments for each individual script
A tree structure containing types of scripts for current project
Ability to run scripts from multiple projects at the same time
** This code is specific to my organization's structured RF
directory. would like to change it to walk through a directory
selected by the user and search through child directories for the name
of the running script's project and then search for Libs, Resources,
Variables, etc and pass those paths as variables to RF
My organization tests different products that have similar
functionality so scripts can be ran to test multiple products, but
each one has it's own set of commands. We have created a common
folder/file/keyword structure so that all we have to do is change the
project to run a script on another product. So the only work that
needs to be done is to create the low level keywords common to all
other projects for that particular project. Porfi in our setup allows
users to just sync our structure from a server, add the scripts to
Porfi select the scripts to run, and run them! No changes to the
scripts need to be made.
Here, we are just beginning to use Robot Framework so maybe some of
these features seem absurd and unneeded or maybe there are features
others would like to see implemented. Any suggestions?
Grompy
Thomas Klein
Grompy
Porfi manages and runs scripts. Didn't you read anything I wrote in
the first post? All of it implies this..
Bryan Oakley
<thomas...@googlemail.com> wrote:
> A RF GUI? Don't we have RIDE already? What's the difference?
I think this discussion is about creating a GUI for executing test
suites, not editing them. See RF issue 709 for the genesis of the
discussion (http://code.google.com/p/robotframework/issues/detail?id=709)
Laurent Carbonnaux
--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To post to this group, send email to robotframe...@googlegroups.com.
To unsubscribe from this group, send email to robotframework-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/robotframework-users?hl=en.
Pekka Klärck
> As suggested by pekka.klarck I will follow all discussion about a GUI
> interface(Porfi) for robot framework here.
Having a GUI to start (and monitor?) execution would be great for
people who aren't so used to the command line. I think it's better to
be a separate project so that it can be improved on it's own phase.
Has anyone else needed such a tool? Anyone has implemented anything
similar?
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
Bryan Oakley
> 2010/12/7 Grompy <gro...@gmail.com>:
>> As suggested by pekka.klarck I will follow all discussion about a GUI
>> interface(Porfi) for robot framework here.
>
> Having a GUI to start (and monitor?) execution would be great for
> people who aren't so used to the command line. I think it's better to
> be a separate project so that it can be improved on it's own phase.
> Has anyone else needed such a tool? Anyone has implemented anything
> similar?
I have something, it's just not quite to the point I'm ready to
release but it's very close. I was planning on doing a personal
hackathon over the Christmas holidays and hopefully release a preview
around the start of the new year. And yes, it's for both starting and
monitoring. And maybe single-stepping through a test, though I'm
having to pull some serious rabbits out of my hat to make that work.
That single-step feature might not make it to the preview release,
it's turning out to be a lot harder to get right than I first thought.
I've got the basic mechanics working but there's just not enough
information exposed in the listener interface to do a good job.
Eventually I think Robot needs one tool rather than two, but I'll save
that discussion for another day.
--bryan
Pekka Klärck
2010/12/8 Bryan Oakley <oak...@bardo.clearlight.com>:
> On Tue, Dec 7, 2010 at 4:17 PM, Bryan Oakley
> <oak...@bardo.clearlight.com> wrote:
>>
>> I have something, it's just not quite to the point I'm ready to
>> release but it's very close....
>
> This reminds me... I've been meaning to ask if you mind if I create a
> google code project for this and give it a name that includes
> "robotframework". I was thinking maybe "robotframework-rdb"
> (rdb="Robot DeBugger").
I have absolutely nothing against you or anyone else starting a
project with `robotframework` in it's name. This is a framework
afteral, and getting more tools into the ecosystem is good for
everybody.
> It's going to grow into something much, much more than a debugger, but
> the good name has already been taken :-)
The only problems I can see with everybody starting new projects is
that good names can be taken and that there can be multiple similar
projects. That's a much better problem to have than not having any of
these projects so there's not much to complain. I believe over the
time the best project will live and stand above others and that
related projects may also merge.
Cheers,
.peke, who's really excited about all the different libraries and
tools released this autumn!
Thomas Klein
and there, some color highlighting in the test tree (red/green) and
show the report.html in an embedded browser once done.
Grompy
I agree that we don't need multiple different tools. However, it
sounds like your designing a debugger. What I have atm is no where
near a debugging tool. It just manages scripts and runs them and post
processes all the ran scripts into a common output file or files
depending on what settings you choose. I'm basically taking the
command prompt away from running scripts and turning it into a GUI.
Including all persistence through open/close so that repetitive script
running is as easy as opening a program and pressing a button. No
more opening a cmd prompt at script location typing in everything,
etc..
On the other hand, this could all be integrated into your program and
make more than just a debugger. Making one powerful tool that can be
used for multiple situations.
I'll try to upload what I have at end of this week sometime so you and
everyone can see the direction I have gone and maybe we can talk about
integrating our programs together into one.
Project is @ http://code.google.com/p/porfi/
It's blank at the moment. Will update this discussion as soon as I
upload my project. Which brings me to a question..
Should the gui be released as a .py or should it be released as an
executable compiled using py2exe?
How do you guys do your installers for RF/ride etc?
Grompy
Bryan Oakley
> @Bryan
> I agree that we don't need multiple different tools. However, it
> sounds like your designing a debugger.
I'm actually creating two things. One is a framework for building
apps. It has a plugin architecture and support for persistent settings
(and a preferences dialog for managing those settings), and is based
on wx.lib.agw.aui. The second piece started life as my test runner
plugin but moved to this new framework. It became the basis for a
debugger, but I'm finding many roadblocks to making that work well.
The robot framework really isn't set up to be able to run
interactively, though I'm still chipping away at the problem and might
have a solution soon.
For the moment I'm back to finishing the part that is used for running
tests. My goal is to be able to let the user define "profiles" which
is really nothing more than a bunch of command line arguments stored
as a single set (there will be a GUI for defining and managing these
sets). For example, you could have a "debug" profile that sets the log
level to debug and only runs tests with the tag "debug". Or, for
example, a "hudson" profile that defines the options we want to use in
our hudson jobs (typically, exclude files with the tag "in-progress",
and a couple other options).
You can then pick one of these sets and click "run" to run and monitor
execution. One of the other features of my runner is that it presents
a tree of the parsed suite and gives you the option to pick individual
tests to run. I'm still deciding how to integrate that with the
profile concept -- should profiles include the names of individual
test cases or suites? That would make the GUI for managing profiles
more complex. The way I'm leaning at the moment is to leave that out
of the profiles. So, to run a specific test you pick a profile and
then select the specific test prior to hitting the "run" button.
What it doesn't have is a way to run a test multiple times, nor the
ability to combine outputs of multiple test runs, both of which seem
to be goals of yours. Though, I could see such features easily be
integrated into my tool as a separate plugin that provides a "test
plan" perspective, where test plans are instructions for running one
or more profiles in a particular sequence. I see a lot of potential
there.
I currently intend to use robot's argument file feature to store these
profiles. Argument files solve 95% of the problem, and for the last 5%
I can embed a little metadata in comments within the file. This way
the profiles can be version controlled right along with the test
files, and used from the command line for batch jobs and whatnot. I'm
open to other ideas, though.
--bryan
Grompy
weekend. Also didn't get a chance to strip work related stuff from
the program so I won't get a chance to up it this weekend either. I
should however be able to sometime next weekend. Thanks for keeping
this discussion going. I love the brainstorming it always helps with
implementing excellent features. Also yes the multiple running is just
a couple simple loops and post processing is as simple as checking to
make sure the individual xml file was created then using rebot to
combine them. My code isn't the prettiest. I really need to comment
a lot of it, but will have it up ASAP.
Grompy
Grompy
> is really nothing more than a bunch of command line arguments stored
> as a single set (there will be a GUI for defining and managing these
> sets). For example, you could have a "debug" profile that sets the log
> level to debug and only runs tests with the tag "debug". Or, for
> example, a "hudson" profile that defines the options we want to use in
> our hudson jobs (typically, exclude files with the tag "in-progress",
> and a couple other options).
their script running however they want. They only downside would be
that setup would take a bit more knowledge, but a default profile and
good documentation would combat that.
> I'm still deciding how to integrate that with the
> profile concept -- should profiles include the names of individual
> test cases or suites? That would make the GUI for managing profiles
> more complex. The way I'm leaning at the moment is to leave that out
> of the profiles. So, to run a specific test you pick a profile and
> then select the specific test prior to hitting the "run" button.
the last scripts each profile ran then I'd think that would be a much
used feature. Many scripts are repeatedly ran after a new build,
release, etc. So remembering the last scripts ran would be a must.
> One of the other features of my runner is that it presents
> a tree of the parsed suite and gives you the option to pick individual
> tests to run.
would be a great feature to implement as well. I initially thought
this would be hard to implement, but after thinking about it robot
framework has the --test keyword which would make this pie to
implement.
> I currently intend to use robot's argument file feature to store these
> profiles. Argument files solve 95% of the problem, and for the last 5%
> I can embed a little metadata in comments within the file. This way
> the profiles can be version controlled right along with the test
> files, and used from the command line for batch jobs and whatnot. I'm
> open to other ideas, though.
scripts and settings. 1 file for scripts and 1 for settings. I don't
know what the best way to do it is. I believe either option would
work just fine.
I'm trying to get what I have up, but I'm having troubles figuring out
how to create the setup.py file. I can up the source could someone
with experience with them help me create one?
Thanks,
Marc
Grompy
installer.
Tested on windows xp 32bit and windows 7 32bit.
Available @ http://code.google.com/p/porfi/
Check it out! Give me some feedback.
Thomas Robinson
I don't know if any of you have used it, but there is the scheduler-
plugin-for-ride [1] which has some of these features you are
discussing and integrates with RIDE. I've been helping to fix some of
the problems with this plugin and, I admit, its still not perfect, but
its getting there. The changes I have made haven't been uploaded to
the project page yet but I've been in contact with the project owner
and he is going to release my changes at some point. I'll provide a
link here if you want to check it out [2]. Just put it in your site-
packages/robotide/contrib directory. (Note that Linux isn't properly
supported yet, unfortunately.)
There is a problem I am currently having with the plugin in RIDE 0.30
and Windows XP for which I have a discussion here: [3]. Hopefully,
someone here can help.
[1] http://code.google.com/p/scheduler-plugin-for-ride/
[2] http://pastebin.com/3GRRZmG4
[3] http://groups.google.com/group/robotframework-devel/browse_thread/thread/ba2aea9af397707f
Thomas
Grompy
MAJOR thing that it lacks that I was attempting to provide is managing
scripts. Sometimes (especially when using synced data from a server)
paths and scripts are buried in multiple directories. It's time
consuming trying to find and use a file. The scheduler as far as I
can see requires that you open the test suite in ride each time you
want to run it. I don't like this at all. If I'm going to open a
program I'd rather open one program and boom I see everything I'm
working with in front of me. I don't like searching repeatedly.
The tool does provide a bunch of interesting features that over time
will probably get implemented into my program.
Thanks for posting the tool. All these ideas are running through my
head and I just want to throw them all in :) If only I had an
infinite amount of time ><
Grompy
On Dec 16, 5:22 pm, Thomas Robinson <robinst...@gmail.com> wrote:
> Hi all,
>
> I don't know if any of you have used it, but there is the scheduler-
> plugin-for-ride [1] which has some of these features you are
> discussing and integrates with RIDE. I've been helping to fix some of
> the problems with this plugin and, I admit, its still not perfect, but
> its getting there. The changes I have made haven't been uploaded to
> the project page yet but I've been in contact with the project owner
> and he is going to release my changes at some point. I'll provide a
> link here if you want to check it out [2]. Just put it in your site-
> packages/robotide/contrib directory. (Note that Linux isn't properly
> supported yet, unfortunately.)
>
> There is a problem I am currently having with the plugin in RIDE 0.30
> and Windows XP for which I have a discussion here: [3]. Hopefully,
> someone here can help.
>
> [1]http://code.google.com/p/scheduler-plugin-for-ride/
> [2]http://pastebin.com/3GRRZmG4
Grompy
Variables. So when a file is added I want to search the file's
directory and the file's directory's directory for keywords such as
Lib, Library, Libs, etc and if it finds it create a ${ProjectLib}
variable to send across the command line and same for resource and
variable so that importing libs, resources, variables can be as easy
as in your script import ${ProjectLib}${\}MyLibrary.py. This would
make it easy to sync to a server and someone else to download add it
then run it. Without changing any paths in the script.
Has anyone encountered this issue and have come to a solution for it?
I've never used an argument file before could an argument file replace
all of this logic?
What kind of directory structures do you guys normally have?
I use
Root -> Workstation Suites -> Libs ->
-> Resources ->
-> Variables ->
-> Product Specific Suites -> Project1 -> SubProject ->
Libs ->
-> Resources ->
-> Variables ->
-> Test Suites->
-> Project2 ->
SubProject -> Libs ->
-> Resources ->
-> Variables ->
-> Test Suites->
-> Common Suites -> ScriptType1 ->
-> ScriptType2 ->
I could strip the project from the metadata and use that project to
search through the parent directories for the project then walk that
directory to find a Lib path.
Otherwise I could play it simple and just add a Set Project Lib Path,
Set Project Resource Path, etc.. options which would then pass that
path to any script ran under that project. I'm trying to take the
annoyances out of RF.
What do you guys think?
Grompy
Grompy
least 1 maybe 2 additional pluggins for ride. This will eliminate
having to have "all kinds of different programs to do different
things" and also help just normal ride users. The first pluggin will
provide a tree like structure for created scripts and scripts opened
up with ride. This will allow users to switch tabs find your script
and open it in your current ride session. This will be more universal
than my current script for mine only handles html. This will handle
whatever ride supports. I'll then convert my current features of
porfi into either another pluggin or into the same pluggin (probably
depending on how well the pluggins can pass data to each other) This
will allow for a more diverse script running and no extra tools to
run.
Grompy