Automated GUI Testing

Using (or providing) components based on the "Win32" framework

Automated GUI Testing

Postby paulmansour on Wed Oct 28, 2015 2:33 pm

I'm in one of my periodic attempts at getting complete coverage of my GUI with automated tests.

One has to approach this problem with foresight. It is virtually impossible to graft on tests after the fact, if the GUI was not written with testing in mind. Thus the importance of writing the tests as you go.

Anyway, even good apriori coding practices, I run into a class of problems that I think may be interpreter related, or perhaps Dyalog could provide a fix for - or perhaps I am missing something obvious.

I can construct a test the runs fine in the tracer, stepping line by line through the code. However, when run normally, it will fail with a value error, or some other error, or some event will not run as expected. There are a variety of cases, and I think they are all from the same problem, but perhaps not.

Obviously the interpreter has time to think and handle events and gui stuff when one traces, but when run normally it cannot catch its breath, so to speak. A well placed ⎕DL or #.Flush is not the answer here.

Some questions:

Is there anything obvious I am missing?

Would it make sense for an ibeam or a root method or some such gizmo that says, hey Mr. Interpreter, do everything you would do, all the housekeeping, etc, that you would do if stopped to trace this line - probably the same stuff you would do If I ran ⎕DQ? I could then insert this into my test functions at strategic points.

Have I created this mess for myself and should I rewrite all my code? (Ugh!)

Any comments or shared experiences appreciated.

Paul
paulmansour
 
Posts: 418
Joined: Fri Oct 03, 2008 4:14 pm

Re: Automated GUI Testing

Postby paulmansour on Wed Oct 28, 2015 2:37 pm

A related question: it appears that HTML5/Javascript is one of the directions we (Dyalog) are going with GUI.

It is, or will it be, possible to write automated tests on a browser based app? All in Dyalog?
paulmansour
 
Posts: 418
Joined: Fri Oct 03, 2008 4:14 pm

Re: Automated GUI Testing

Postby paulmansour on Wed Oct 28, 2015 3:15 pm

Regarding my last question, I see Dyalog mentions an outfit called Selenium on the MiServer site as an options for testings...
paulmansour
 
Posts: 418
Joined: Fri Oct 03, 2008 4:14 pm

Re: Automated GUI Testing

Postby MBaas on Wed Oct 28, 2015 6:19 pm

I can only comment on the HTML-aspect of the question: you are right, Selenium is an definitely an option. Morten has put up some code on GitHub which I am using to test my code. And I assume that's only the beginning! ;-)
User avatar
MBaas
 
Posts: 156
Joined: Thu Oct 16, 2008 1:17 am
Location: Gründau / Germany

Re: Automated GUI Testing

Postby Morten|Dyalog on Fri Oct 30, 2015 8:08 am

We are working on a response to the original question... Meanwhile, I just wrote a little piece about our experience with Selenium. It *is* the Bee's Knees!

http://www.dyalog.com/blog/2015/10/over-the-moon-with-selenium/
User avatar
Morten|Dyalog
 
Posts: 451
Joined: Tue Sep 09, 2008 3:52 pm

Re: Automated GUI Testing

Postby Tomas Gustafsson on Fri Oct 30, 2015 11:21 am

Good clip. This is excellent!

But i wonder if the same for Windows GUI fails on various focus/unfocus and event que timing/ordering issues? Sounds rather tricky to trace those. Just came to my mind, that one maybe should somehow use 2 computers, the first one driving a GUI on the second one. The idea being that a crash on the first one (where the code runs) wouldn't alter input focus on the 2nd one (where the GUI is). Then a →⎕LC on the first one would have the GUI (especially the input focus) available intact on the 2nd one.

By intuition :-). I may be totally wrong.
Tomas Gustafsson
 
Posts: 101
Joined: Mon Sep 19, 2011 6:43 pm

Re: Automated GUI Testing

Postby paulmansour on Fri Oct 30, 2015 2:53 pm

So it turns out I had a function in my workspace that does precisely what I need!

I collaborate with Kai, who developed a fix for this problem for testing a full-featured grid.

I could have sworn in the past that I attempted such a solution but could never get it to work.

Here is my adaptation of Kai's solution:

      ∆DQ←{                                    ⍝ Dequeue form ⍵ for ⍺ seconds
⍺←0 ⍝ Default delay
_←⍵.⎕WS'Event' 9955 1 ⍝ Exit ⎕DQ on 9955
_←⍺{_←⎕DL ⍺ ⋄ ⎕NQ ⍵ 9955}&⍵ ⍝ Thread enqueued event
_←⍵.Wait ⍝ Wait for ⍺ seconds
0
}


It turns out that in the particular case I was working on, a delay of 0 is sufficient; simply entering and exiting DQ immedietly works.
paulmansour
 
Posts: 418
Joined: Fri Oct 03, 2008 4:14 pm


Return to Windows: GUI, COM/OLE/ActiveX

Who is online

Users browsing this forum: No registered users and 1 guest