Automated Tests with the Grid

[paulmansour]

Hi all,

I’m trying to automate some tests involving the grid object. The goal is to emulate as closely as possible what actually happens in a run-time environment, with a user entering key strokes.

The following script sets up a very simple example. If you trace the SampleTest function, the test passes. If you execute it, it fails. How can I get it to pass under normal execution?

Clearly the callback function attached to the CellChanged event only gets called when we execute one line at a time in the trace, and not when we execute continuously. It appears the events are stacking up in the event queue. I thought the left argument of 1 for []DQ would fire the callback immediately instead of adding it to the event queue (When I do automated GUI tests not involving a grid, this appears to be the case.)

I have tried various things to no avail. I have tried going into a quad DQ to give the events a chance to fire and then exiting immediately, but no luck.

Am I missing something trivial?

Bonus question:

I would prefer to fire the KeyStroke event on the grid itself rather than the associated edit object from the Input property. This would allow me to change the underlying implementation without changing the tests. But I can’t get it to work that way. Any ideas?

Any help would be greatly appreciated.

Code: Select all

:Namespace AutoTestExample
     
    ⎕ML←3
    ⎕IO←0

      BuildSampleForm←{
          _←'f'⎕WC'Form'
          _←'f.g'⎕WC'Grid'('Size' 100 100)
          _←'f.g.c1'⎕WC'Edit'
          _←'f.g.c2'⎕WC'Edit'
          f.g.Input←'f.g.c1' 'f.g.c2'
          f.g.CellTypes←3 2⍴1 2
          f.g.onCellChanged←'OnCellChanged'
          v←3 2⍴'One' 'Two' 'Three' 'Four' 'Five' 'Six'
          f.g.Values←v
          f.g._CellChanged←(⍴v)⍴0
          f
      }
 
      OnCellChanged←{
          g r c←⍵[0 2 3]
          g._CellChanged[r;c]←1
          0
      }
   
      Press←{
          r c←⍺.CurCell
          e←⍺⍎c⊃⍺.Input
          80=⎕DR ⍵:{0}1 ⎕NQ e'KeyPress'⍵
          _←1 ⎕NQ e'KeyPress',⍵
          0
      }

      PressEnter←{
          ⍺←⍵
          ⍺ Press'ER' 0 13 0
      }
     
      PressRight←{
          ⍺←⍵
          ⍺ Press'RC' 0 39 0
      }
     
      Type←{
          r c←⍺.CurCell
          e←⍺⍎c⊃⍺.Input
          _←e{1 ⎕NQ ⍺'KeyPress'⍵}¨⍵
          0
      }


      SampleTest←{
          f←BuildSampleForm 0
          g←f.g
          _←f.g.CellMove 0 0
          _←g Type'John'
          _←g PressEnter 0
          _←g Type'Paul'
          _←g PressRight 0
          _←g Type'George'
          _←g PressEnter 0
          ⎕←g._CellChanged
          z←g._CellChanged≢3 2⍴1 0 1 1 0 0
          _←f.Close
          z
      }
 
:EndNamespace


[gil]

Hi Paul

I'm not sure why the events are not triggered immediately when the left argument to ⎕NQ is 1, the documentation clearly suggests they should. I know they get triggered if you ⎕DQ the form. I have modified you SampleTest function by adding a user defined event to the form which is enqueued in the end of your test. A final dequeue on the form allows all events to be processed and leaves when it's done.

Code: Select all

      SampleTest←{
          f←BuildSampleForm 0
          _←f ⎕WS('Event' 1234 1)
          g←f.g
          _←f.g.CellMove 0 0
          _←g Type'John'
          _←g PressEnter 0
          _←g Type'Paul'
          _←g PressRight 0
          _←g Type'George'
          _←g PressEnter 0
          _←⎕NQ f 1234
          _←⎕DQ f
          ⎕←g._CellChanged
          z←g._CellChanged≢3 2⍴1 0 1 1 0 0
          _←f.Close
          z
      }


[paulmansour]

Hi Gil,

That works, thanks!

I tried something similar in my real case (not the simple example) and couldn't get it to work. I think I was firing an using an existing control that was supposed to exit ⎕DQ....

Anyway, this is a great work around.

Vince, if you are listening in, is this a bug that the event is not fired immediately?

Paul

[Vince|Dyalog]

Hi Paul,

I've asked my colleagues about this.

We think the 1 ⎕NQ documentation applies to direct events like the KeyPress event and not side-effects like the CellChanged event. They are enqueued as normal. As you will recall, there is an implicit ⎕DQ when you're stepping through lines in the tracer.

Gil's answer is the way to go. Thanks Gil!

Regards,

Vince

[kai]

> We think the 1 ⎕NQ documentation applies to direct events like the KeyPress event and not side-effects like the CellChanged event. They are enqueued as normal.

If that is so then the documentation should mentioned it.

Also, the documentation should provide a list of events considered "side effects" or - probably better - generate a distinctive error when posted via 1 ⎕NQ. The definition of what is a side effect does not seem to be sufficiently clear to me.

> As you will recall, there is an implicit ⎕DQ when you're stepping through lines in the tracer.

Why would Paul recall this? I certainly wouldn't. Is that mentioned anywhere in the documentation?

When I wrote automated GUI tests for Fire I had to add some ⎕DQs which quit themselves via a timer between certain GUI-related actions to make it work (at least most of the time) even when tracing through the code.

How is that effecting the behaviour of the Tracer when used via RIDE?

[Vince|Dyalog]

Hello Kai,

In our Interface Guide/Chapter 1: Introduction/User Interaction & Events:

A second task for ⎕DQ is to cause the system to wait for user events. Objects that you
create are immediately active and capable of generating events. During development
and testing, you can immediately use them without an explicit wait. However, unless
your application uses the Session in conjunction with GUI objects you must call ⎕DQ
to cause the application to wait for user input. In a run-time application, ⎕DQ is essential.

I will rephrase my statement to--1 ⎕NQ immediately executes the callback for the event which you explicitly enqueue. All other events which are side-effects of this action are added on to the queue and will be processed by ⎕DQ as normal.

The implicit ⎕DQ that is in the development environment will be the same under RIDE as in the current development environment. It will happen whether stepping through the tracer or while sitting in the session.

Regards,

Vince