Use RF to test server client application

[Eileen Wei]

Hi,

I have a test scenario like the following:

1. Set up the server
2. Set up the client
3. Do something on the client
4. Check something on the server

Is there any way that I can use RF to drive this test?

Thanks,
Eileen

[Eileen Wei]

I forgot to mention that server and client are on different machines,
and preferably on VMs.

[Magnus Smedberg]

I don't see any reasons why you shouldn't be able to do this with
RF. :-)
There are really good libraries available that can help you with this
sort of testing. SSHLibrary is one of them that can be really helpful.
However, it's really hard to give any suggestions or help given the
limited information you provided.

What is involved in each of your steps? What kind of interfaces are
available? Which OS:s are the client/server running on?

If you give a bit more details, I'm sure you can get a good answer or
suggestion on how to proceed from the people in this UG. We're usually
very friendly. ;-)

BRs
Magnus

[Eileen Wei]

Thanks Magnus for your reply, and I do know this is a very friendly
group :)

Here are the details:

-Both client and server run on Windows (I am not very familiar with
SSH, and I have only used it briefly on Linux - does SSH run on
Windows?)
-Set up server on machine 1 by installing server service from an
installer (.exe) - GUI interface
-Set up client on machine 2 by installing client application from an
installer (.exe) - GUI interface
-On client machine, launch client application (GUI) and connect to
server
-On server machine, check client connection status (GUI)

I can probably use AutoIt library to drive the GUI, but my biggest
question is how to coordinate the client/server action in RF since
they are happening on different machines?

Any suggestions will be greatly appreciated!

Thanks,
Eileen

[fkberthold]

Hi Eileen,

We have a very similar situation on our system and have been able to
solve it neatly using the remote library interface:
http://robotframework.googlecode.com/svn/tags/robotframework-2.5.3/doc/userguide/RobotFrameworkUserGuide.html#remote-library-interface

The short version of what this does is your run a remote agent on the
systems you need to control and through this you can execute python
code. What we've done is two separate things:
1. We use python's subprocess library to execute arbitrary commands
in the OS.
2. We use RF's OperatingSystem library to be able to move files
around on the system etc

Most gui installers have a silent option available, if this is so, you
can simplify your life by installing from a config file, this is a lot
easier and more predictable than trying to interact with the GUI
through AutoIT. Failing that, it should be equally easy to use the
autoIT library on the remote system.

There are two things you need to be aware of when doing this though:
1. You'll need to install python and any of the necessary libraries
on the machines you're running remote on.
2. The initial connection time to remote is a bit slow, I've waited
as long as 30 seconds for it to make it's initial connection, once
connected though it seems to run decently fast.

I hope you find this helpful,
Frank

[Eileen Wei]

Hi Frank,

Thank you very much for your reply. I read the remote library session
and played with the examples, it's really cool!

But I still have some questions here:
1. I am thinking of having a control machine, which runs the RF test
data, and a server machine and a client machine, which will be running
remote servers (does it sound like a good plan?). I'm wondering how
would you start the remote servers from the control machine?
2. I understand how to implement a custom library in the remote
system, but how to use the RF library such as OperatingSystem and
AutoIt (yes I can use silent install but I believe for some test steps
I cannot avoid GUI totally) from the remote system? The user guide and
examples didn't talk about this, is it something obvious but I missed?

Thanks again,
Eileen

On Sep 23, 8:24 am, fkberthold <fkberth...@gmail.com> wrote:
> Hi Eileen,
>
> We have a very similar situation on our system and have been able to

> solve it neatly using the remote library interface:http://robotframework.googlecode.com/svn/tags/robotframework-2.5.3/do...

[Eileen Wei]

I have done some more reading and found answer to my first question -
I think I would use STAF (http://staf.sourceforge.net/) to start the
remote server from the control machine. I haven't decided whether I
should do STAF in the start up batch file or do it inside RF - any
suggestions?

But I am not able to find solution to my second question - how to use
more than one libraries from the remote system? I would like to use RF
standard and external libraries from the remote system as well. I have
searched for related discussions but don't seem to find a concrete
answer - is this something RF support naturally or does it need a lot
of customization? If the latter, can someone give me some instruction?
I am thinking anyone using RemoteLibrary would have had the same
question and there is probably already a solution :)

Any suggestions will be greatly appreciated!

Have a good weekend everyone!
Eileen

[Pekka Klärck]

2010/9/25 Eileen Wei <eileen...@gmail.com>:

> I have done some more reading and found answer to my first question -
> I think I would use STAF (http://staf.sourceforge.net/) to start the
> remote server from the control machine.

I would have actually recommend STAF because I had pretty good
experience when I used it several years ago. Back then I used their
STAX language, but I've grown so allergic for using XML for scripting
that I'd nowadays just use the STAF services directly from Python (or
some other language they support).

STAF is good choice especially if you have machines with multiple
operating systems and some of them have Windows. If you only have
unixy machines, you can often do easy tasks like copying files and
starting processes simply using SSH and SCP.

One relatively new tool that might work in your case is Fabric
<http://fabfile.org/>. I've never used it myself, but it looks really
cool for all kind of deployment tasks. I'm sure there are other
possibilities too. What tools have others used? How did they work?

> I haven't decided whether I should do STAF in the start up batch file or do it inside RF - any
> suggestions?

This depends on the context, but typically I try to do this kind of
setup before starting the actual test execution.

> But I am not able to find solution to my second question - how to use
> more than one libraries from the remote system?

Currently you need to start multiple remote servers to different
ports. You can then take the libraries into use like this:

*** Settings ***
Library Remote http://1.2.3.4:1234 WITH NAME First Lib
Library Remote http://1.2.3.4:1235 WITH NAME Second Lib

We've discussed making it possible for one remote server to host
multiple libraries, but nobody has yet had time to implement this
support.

> I would like to use RF standard and external libraries from the remote system as well.

Basically you need to install the needed libraries into the remote
machine separately. With Python libraries that can only mean copying
the source files, and there's even an interesting enhancement idea to
make possible to upload libraries via the Remote interface:
http://code.google.com/p/robotframework/issues/detail?id=587

Some of the standard libraries require also Robot Framework itself to
be installed on the same machine, but you can try to remove those
dependencies if installing the framework to the remote machine isn't
easy. That has actually been done for the OperatingSystem to some
extend: http://code.google.com/p/robotframework/issues/detail?id=181

Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Eileen Wei]

Thanks Pekka for your reply! I will install RF on the remote system as
well, so in order to use for example OperatingSystem Library from the
remote system, I need to add the following into OperatingSystem.py -
is that correct?

if __name__ == '__main__':
from robotremoteserver import RobotRemoteServer
RobotRemoteServer(OperatingSystem(), *sys.argv[1:])

Also, I think the idea discussed in http://code.google.com/p/robotframework/issues/detail?id=587
will be very helpful in my scenario, so I am wondering about its
release decision as well as if I can use it before it gets released?

Thanks,
Eileen


On Sep 25, 3:28 am, Pekka Klärck <p...@iki.fi> wrote:
> 2010/9/25 Eileen Wei <eileen.ly....@gmail.com>:

[Pekka Klärck]

2010/9/27 Eileen Wei <eileen...@gmail.com>:

> Thanks Pekka for your reply! I will install RF on the remote system as
> well, so in order to use for example OperatingSystem Library from the
> remote system, I need to add the following into OperatingSystem.py -
> is that correct?
>
> if __name__ == '__main__':
>    from robotremoteserver import RobotRemoteServer
>    RobotRemoteServer(OperatingSystem(), *sys.argv[1:])

This should work. I'd probably create a separate script with this kind
of content:

import sys
from robot.libraries.OperatingSystem import OperatingSystem

from robotremoteserver import RobotRemoteServer
RobotRemoteServer(OperatingSystem(), *sys.argv[1:])

> Also, I think the idea discussed in http://code.google.com/p/robotframework/issues/detail?id=587
> will be very helpful in my scenario, so I am wondering about its
> release decision as well as if I can use it before it gets released?

I like the idea too. I'd like to see the implementation before
commenting can it be incorporated with the current remote
infrastructure, though.

[fkberthold]

Hi Pekka,

There's a slightly hackish workaround to having to import multiple
libraries if you're always going to be using the same ones, that's by
creating a super class that contains all of the classes that are of
interest, ie:

In a file myRemoteServer.py:
import OperatingSystem
import AutoItLibrary

class myRemoteServer(OperatingSystem.OperatingSystem,
AutoItLibrary.AutoItLibrary): # Actual class names may differ, I'm
doing this off the top of my head.
pass


Then at that point you just have to import the super class via remote.

I hope this is useful,
Frank

On Sep 25, 5:28 am, Pekka Klärck <p...@iki.fi> wrote:
> 2010/9/25 Eileen Wei <eileen.ly....@gmail.com>:
>

[Pekka Klärck]

2010/9/28 fkberthold <fkber...@gmail.com>:

> Hi Pekka,
>
> There's a slightly hackish workaround to having to import multiple
> libraries if you're always going to be using the same ones, that's by
> creating a super class that contains all of the classes that are of
> interest, ie:
>
> In a file myRemoteServer.py:
> import OperatingSystem
> import AutoItLibrary
>
> class myRemoteServer(OperatingSystem.OperatingSystem,
> AutoItLibrary.AutoItLibrary): # Actual class names may differ, I'm
> doing this off the top of my head.
>  pass
>
>
> Then at that point you just have to import the super class via remote.

This is very clever hack! The will be problems if libraries have
conflicting methods or other state, but in many cases this probably is
enough.

[Eileen Wei]

I wanted to report that I have tried it and it works for me!

Thanks a lot :D

-Eileen

[binithb]

Hi there,

I reached this thread after following a lot of links here and there.
This is almost the answer I was looking for.

However since its been more than 2 years since this discussion took place, I was  wondering whether anything has been added in RF to make this kind of scenario any simpler.

I mean for me it looks like a standard feature to be able to reuse existing libraries (OperatingSystem, Builtin etc) on the remote host without having to write a custom class for that.

Indeed the custom class will be required if we need to have a custom operation to be done on a remote host, but just to be able to start another process on the remote host ( an operating system lib feature, same requirement as Eileen), dont you guys think the "RobotRemoteServer" itself can have all the default libraries built into it .

This idea from Greg also looks good.

https://groups.google.com/d/topic/robotframework-devel/yfN-dzPzXnM/discussion
this way we will only be (dynamically) loading the required default libraries rather than statically loading all the custom libraries as suggested by fkberthold

If there is any progress on this front or a better way if doing it, please share


thanks,
-binith

[Pekka Klärck]

2013/2/27 binithb <bin...@gmail.com>:

>
> However since its been more than 2 years since this discussion took place, I
> was wondering whether anything has been added in RF to make this kind of
> scenario any simpler.

Unfortunately the Python remote server hasn't been really improved
since this discussion. I started moving it into a separate project
where developing it further would be easier but that task got stalled.
I'd really like to re-start this project, but I'm not sure when I have
time. Are there people who'd be interested to help with it? I would
like to participate in this project but wouldn't mind someone else
taking more responsibility on it.

> I mean for me it looks like a standard feature to be able to reuse existing
> libraries (OperatingSystem, Builtin etc) on the remote host without having
> to write a custom class for that.

I agree it should be easier to host multiple libraries on one remote
server. They could, for example, be served on different paths like
http://server:8270/OperaratingSystem and http://server:8270/MyLib. The
way you currently can do this, without having a class wrapping all
libraries, is starting multiple remote servers on different ports.

> Indeed the custom class will be required if we need to have a custom
> operation to be done on a remote host, but just to be able to start another
> process on the remote host ( an operating system lib feature, same
> requirement as Eileen), dont you guys think the "RobotRemoteServer" itself
> can have all the default libraries built into it .

First of all, the only standard library that really is actually useful
on a remote machine is OperatingSystem. It can see that including it
into the remote server would give some benefits, but I'm not sure is
that worth the effort. It couldn't be activated by default anyway
because otherwise there would be keyword conflicts always when you
used Remote and OperatingSystem together. Keeping the included library
updated would also be some extra work.

> This idea from Greg also looks good.
>
> https://groups.google.com/d/topic/robotframework-devel/yfN-dzPzXnM/discussion
> this way we will only be (dynamically) loading the required default
> libraries rather than statically loading all the custom libraries as
> suggested by fkberthold

Being able to load libraries from a machine where Robot is running to
a machine where remote server is running would be really cool.
Definitely no need to include OperatingSystem with the remote server
if this feature is implemented. It should definitely be included in
the possibly enhanced remote server.

[binithb]

Hi Pekka,

Thanks for the time.

As I understand , the most relevant section of your comments is the following one

Being able to load libraries from a machine where Robot is running to
a machine where remote server is running would be really cool.
Definitely no need to include OperatingSystem with the remote server
if this feature is implemented. It should definitely be included in
the possibly enhanced remote server.

So if I figure out a way to do this, then all other requirements will get solved as it is.

Please correct me if my understanding is wrong.


thanks,
-binith

[Pekka Klärck]

2013/3/8 binithb <bin...@gmail.com>:

>
> Hi Pekka,
>
> Thanks for the time.
>
> As I understand , the most relevant section of your comments is the
> following one
>
>
> Being able to load libraries from a machine where Robot is running to
> a machine where remote server is running would be really cool.
> Definitely no need to include OperatingSystem with the remote server
> if this feature is implemented. It should definitely be included in
> the possibly enhanced remote server.
>
>
> So if I figure out a way to do this, then all other requirements will get
> solved as it is.
>
> Please correct me if my understanding is wrong.

Knowing how to do this technically is definitely the first task. Then
we still needed to agree what kind of API would work best.

[binithb]

I have a vague idea to use Python mixins to do this, so that I can make the remote server import and load any required python module(read robot framework test library).
I must say that I have not used mixins before, but i think it will be handy in this scenario.
Do you think mixin is the right direction ?

[binithb]

Just wanted to another point about remote library execution, in addition to the one mentioned below.
Usually , in addition to the RF libraries available as python libraries, we will be adding many user keywords of our own.
When we work with remote library , to begin with we will need to invoke the default test library keywords (Like you said, these will be mostly Operating System calls)
Now, In addition to these we will also need to run some user keywords as well. ("Get Product Log Path" may be an example for user keyword, which internally calls OperatingSystem calls)
Ideally I will want to use the user keyword "Get Product Log Path" to be working in the local server as well as in the remote server.
Currently Is there a way to get this also working with RF ?

If not, do you guys have any approach/roadmap defined for this or will  this have to be implemented freshly from ground (Any workarounds are also welcome)

thanks,
-binith

[binithb]

Requesting for comments :)

[Kevin O.]

The aliasing for libraries can help you accomplish this.

Library    MyLibrary

Library    Remote    http://192.168.0.1/MyLibrary    WITH NAME    MyLibraryOnSystemA

MyLibrary.Get Product Log Path    # executes locally

MyLibraryOnSystemA.Get Product Log Path    # executes remotely

If you want, you can set the library search order so that you only need to use the full keyword name when trying to execute remotely:

Set Library Search Order    MyLibrary    MyLibraryOnSystemA    # in a suite setup

Get Product Log Path    # executes locally, would cause error if Set Library Search Order was not set

MyLibraryOnSystemA.Get Product Log Path    # executes remotely

Kevin

[binithb]

Thank Kevin.
I guess I am looking at something beyond this.

To describe , I will expand the user keyword that I use one level up
Now I need the keyword

"Get Log Path of Product A"

Within the definition of "Get Log Path of Product A", it will be calling existing keyword .Get Product Log Path (A as arg)

Going by the approach mentioned below, I will need to maintain two copies of "Get Product Log Path A" and Get Product Log Path (A as arg) in both Local library as well as remote library.
And this repeating and duplication will increase as the levels of user keywords increase.

Where as in essence, the action performed by both the user libraries are the same, the only difference being where the actual command gets executed (one locally another in Server X)

So ideally (IMO) if there was a (Remote)OperatingSystem library which optionally takes the IP as argument, I will need to maintain only one copy of user keywords. I will not have to maintain another library just for remote execution of operating system keywords.

Indeed the implementation details of such a library needs to be discussed further, but do you think such a requirement is relevant or  am I going in a wrong direction .

I mean I may be missing something ,  please get me up to speed if my thought process is wrong.

thanks
-binith

[Kevin O.]

I think I understand what you are saying. It would be nice if what you are trying to accomplish was easier.

Keep in mind that user keywords refer to keywords implemented in RF's syntax and cannot be run on the remote server.

If I were in your position, I would implement a dynamic API library that is essentially a wrapper around Remote library.

I would use robot.utils.ConnectionCache to hold multiple instances of Remote (this is what SudsLibrary, SSHLibrary, & Selenium2Library do).

get_keyword_names would return the same as OperatingSystem except these two added keywords: add_operating_system_host and switch_operating_system_host

add_operating_system_host would put an instance of Remote into the cache and take a URL argument

switch_operating_system would take aliases or a special value localhost. when set to localhost, the library would dispatch to OperatingSystem instead of Remote.

User keywords would not need to know what system they are dealing with. It would be up to the test case or perhaps high-level user keywords to switch the context to the appropriate system.

You should not have to duplicate keywords.

Good luck

[binithb]

An update/related info is updated in the this (dev group) thread

https://groups.google.com/forum/?fromgroups=#!topic/robotframework-devel/iUH6-P5lMxk