Hi,
I am totally lost what you want, but :)
I guess you can always trap the events generated by different controls and
rise some flags and check them if the program is ready to accept next input.
This is in case that you want to simulate a real user input. If you want to
see what will happen if user just make random clicks and inputs ... hmmm,
brute force is the name :)
And also, I do not thing that you need to simulate mouse clicks and key
presses (I assume that this is well implemented in the framework), and you
want only to see the result of any different combination of inputs (i.e.
what happens if checkbox1 is selected, textfield1 contains "blabla" and user
clicks OK button). So, in your timer thread you may set a flag that it is
not finished yet, set these controls to testing values and invoke the click
event of the button. And when the corresponding operation of the click event
finishes, just set the flag back to show that the test thread can be run
again. Just create the threat in static class, and lock it while it is
executed, so you will not have 2 simultaneous executions.
Sunny
"Daniel Goldman" <hh******@yahoo.com> wrote in message
news:69**************************@posting.google.c om...
Thanks for response, it's a step in right direction, even
though basic problem remains. I think the thread needs to:
1) generate random number
2) make event happen, based on number
3) wait for program to respond, then back to 1)
On step 2), naive brute force way might be the thread somehow
generates mouse clicks and keyboard events. By itself, probably
won't work. GUI events need to know about sending control, and
be linked to called object. Right?
Also, brute force might fail to fully run program. Some sections
might fail to execute. Most mouse clicks "miss the mark".
A more realistic way might be fire events specifically tied
to controls on the interface. Maybe some way to register all
controls with a central class, by implementing an interface.
The central class could know which part of the program was
currently in operation, and adjust how it generates events.
Another possibility - A separate program generates mouse
and keyboard events on the interface. This is similar to
brute force method. Problem is - how would it know to wait?
Step 3) wait is required so sequence is repeatable, each self-run
based on a seed is the same. I've glanced at lock, Pulse(),
and Wait(), which should work and be better than Timer, since
some operations just take split second, others many seconds.
Daniel Goldman
"Sunny" <su******@icebergwireless.com> wrote in message
news:<OX**************@TK2MSFTNGP10.phx.gbl>...
Why don't you try to start a separate threat to generate inputs? Just
for fun :)
You may start it as timer event as an example.
Sunny
"Daniel Goldman" <hh******@yahoo.com> wrote in message
news:69**************************@posting.google.c om... I have a C program that analyzes data. It makes tables,
graphs, other output in response to user selections.
It normally takes keyboard input into a curses-based user
interface. However, it can also run itself, forever or
until it crashes. For self-run, "input" is based on random
numbers. The self-run is useful for testing (and fun).
I'm porting the program to C#. It will have tab controls,
buttons, menus, dialog boxes, list boxes... Any ideas how
to do this kind of self-run mode for a C# desktop app?
Not looking for advice about structured testing, random #
generation, other basics. :) I'm looking for info about
automated testing like this in C# desktop app. I write
code in a text editor.
Thanks,
Daniel Goldman
