wintest for testing Samba against windows

Sam Liddicott sam at
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). ? (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 mailing list