Re: [Xnee-devel] Verifying GUI-Testresults with xnee using the tools "xcutsel" and "xprop"

[Henrik Sandklef]

On Mon, 2006-01-16 at 16:53 +0200, Veijo Ryhänen wrote:
> Hello!
> 
> Currently screen capture based test results verifying seems to be too
> difficult, too 
> time consuming and too complicated solution for me: Verifying
> GUI-Testresults with 
> xnee using the Tool
> "xgrabsc" (http://savannah.gnu.org/support/?func=detailitem&item_id=103871).
> Anyway, I gave 50 vote for this "picture based" solution. Hopefully it
> will be
> easier to do in the future.

It will :)

The idea is to provide a set of scripts that the users can customise for
its own purposes. 

Will just make sure that the solution will be generic enough.

> Instead I tried character based test results verifying. This is how I
> did it:
>.....
> Wish list:
> ----------
> 
> How about "--cut_buffer 0" -switch in cnee ? I would like to use
> it instead of xcutsel. If "--cut_buffer 0" switch is defined, then
> cnee will "copy PRIMARY to 0" when pressing stop key. 
> When using "--cut_buffer 0", only thing to remember before pressing 
> stop key is to copy test result string to clipboard. It would be
> little bit easier to record tests when using "--cut_buffer 0" -switch.

Xnee does record and replay (and synchronise). 

If attempting to solve generic result comparison Xnee will get too
complex and too hard to maintain, I think. How many cut/paste solutions
are there? How many other ways are there to verify the result, be it
graphical or not? 

Xnee will use external tools (triggered from Xnee) to achieve this. This
way Xnee needs no knowledge on for example the cut/paste implementation.

Until GUI test verification support* is implemented I think a much
easier solution would be to print stuff (from your application which is
being tested) to stdout and store that in a file. If the two files
(created while recording and while replaying) are identical we can
assume the test was ok.

Any thoughts on this are welcome!!!

/hesa


*) This will be done by letting Xnee invoke scrips/binaries instead of
doing the job itself.