wintest for testing Samba against windows
sam at liddicott.com
Sat Nov 20 04:02:51 MST 2010
On 20/11/10 10:39, tridge wrote:
> Hi Sam,
> > I've done some work testing windows against samba servers.
> yep, you're was the most extensive we've seen to date, but
> unfortunately we didn't get it to the stage that it was run regularly
> by Samba developers. I'm hoping this new effort will be something that
> quite a few developers run as part of their normal development process.
> > I found that a cygwin ssh (and I guess windows telnet) client session
> > didn't and couldn't share the same mapped drives as a logged in windows
> > session for the same user.
> right, and I get the same thing with telnet. It hasn't been a problem
> so far as I haven't been trying to run GUI commands. I've mostly been
> concentrating on the domain operations (dcpromo, repadmin etc) that
> are so important for Samba4.
> > Another similar approach that I've used is a daemon (maybe python) that
> > gets launched as part of the login script that then listens for commands.
> > (You can login with rdp entirely on the command line and have the login
> > script launch the daemon to take it from there).
> do you mean by using the -s switch to rdesktop? I haven't had any luck
> making that work.
No, I meant just having something start from the startup program group,
or from the login script.
> > For controlling explorer.exe or notepad to do tests, I used a patched
> > Win32::Test from perl to send window messages and select menu choices,
> > press buttons, etc.
> I tried something similar last year, but never found it reliable
> enough. I might look into that again in the future, but for now I've
> found that we can cover a pretty large part of the functionality of
> Samba4 using telnet and remote admin tools. Controlling windows GUI
> apps would be great, but only if it was very reliable!
Well I'm just starting some more extensive work on that. Reliability is
a problem as you say, and has caused me to develop a set of helper
functions so that actions can easily be scripted that wait for specific
window change combination; like run a program and wait until a new
window of a certain class appears - rather than the common: send these
keystrokes and wait 5 seconds. I have operations to mount network
drives, and so forth, using the windows dialogs. It's important for me
to use the UI for testing because for network operations are generated
when the UI is used, as windows gathers the information it needs for
auto-completion and the like.
But it can be long winded to write operations to be able to recognize
the different window combinations by which failures may be shown.
The changes to win32 were so that instead of executing code sections in
the applications thread (which wasn't working), I allocate memory to the
thread, initialize it with values and then send windows messages where
lparam points to the memory allocated to the thread, and then copy back.
If you are strongly tipped to python, then maybe I should bite the
bullet and use that (as my colleague plans to use it for tests). ?
http://www.tizmoi.net/watsup/intro.html (if it works out of the box) may
be quicker than continuing to fixup Win32::Test
I think I'm inclined to do that; plus learning a new language always
makes the task less mundane.
More information about the samba-technical