Comprised of one class :
- TestIup.lua
-
In Lua it is easy to override any function. This is also
possible for libraries (as is the IUP framework) and because
of the mechanics of the
require
function, it is even possible to do this before the library is actually called in the GUI program. The way this works is as follows :- - setup (in
TestIup.lua
) -
- Remove all IUP classes from the global environment
- Load IUP (again ?)
-
Replace the
iup.MainLoop
andiup.SetIdle
functions -
Subsequent
require
's of IUP will not load the library anymore (just run it).
- - run test
-
The test class will
require
the GUI program. This will (load and) run it. Since theiup.MainLoop
is not active anymore the GUI will not start. In this stadium it is possible to verify that all required GUI interface elements are loaded and/or to test methods in the GUI program.
It is also possible to test the GUI dynamically. For example :----------------------------------------------------------------------------- -- Demo unit test for iuptree2.wlua -- Same test function 'new style' (all local variables) -- @release 0.0.0 ----------------------------------------------------------------------------- local test = require('btd.lua.testapi') local testIup = require('btd.lua.testiup') TestIupTree2New = {} function TestIupTree2New:setUp() -- start GUI program on every test method dofile('btd/lua/test/iuptree2.wlua') end function TestIupTree2New:test_createNewStyle() local function idleLoop(t) -- exit GUI after 2 s return function() if (os.clock() - t) < 2 then return iup.DEFAULT else return iup.CLOSE end end end test.equals(tree.name0,'Animals') -- check presence of GUI elements test.equals(tree.name1,'Mammals') test.equals(tree.name2,'Horse') test.equals(tree.name3,'Whale') test.equals(tree.name4,'Crustaceans') test.equals(tree.name5,'Shrimp') test.equals(tree.name6,'Lobster') test.equals(tree.state0,'EXPANDED') test.equals(tree.state1,'EXPANDED') test.equals(tree.state4,'EXPANDED') local t = os.clock() testIup.iupLoop(idleLoop(t)) -- start GUI, do idle loop processing -- 'somehow' the 'Crustaceans' branch should be closed test.equals(tree.state4,'COLLAPSED') end
The waytestIup.iupLoop
works depends on :- - no parameter (
testIup.iupLoop()
) - The GUI program will start and will stop the first time idle loop processing is called for
- - parameter and no idle loop in GUI program (
testIup.iupLoop(idleLoop(???)
) -
The GUI program will start and will, every time
idle loop processing is called for, call the
idleLoop
function. The GUI program will stop when that function returnsiup.CLOSE
- - parameter and idle loop in GUI program (
testIup.iupLoop(idleLoop(???)
) -
The GUI program will start and will, every time
idle loop processing is called for, call the GUI program
idle loop function, followed by the test
idleLoop
function. The GUI program will stop when that last function returnsiup.CLOSE
- - no parameter (
- - test robot
-
Now, the testing side of the equation works. The
means to statically and/or dynamically check a GUI
are present. However, unless we want to condemn
ourselves to manually activate the GUI while it is
under 'automatic' test we need something more : a
test robot. Ideally this would be part of the test environment
itself :
- Generate keyboard events (low level)
- Generate mouse events (low level)
- Generate time based keyboard and/or mouse events to be able to actually see what is happening or as a demo function (low level and/or lua)
- Lookup coordinates of GUI elements and generate 'high level events' as 'click GUI button', 'enter GUI text',... (lua)
- The 'low level' parts (see above) can't be written in Lua (C or C++).
- There is not only an operating system dependency, but also (or more so) a 'windowing environment' one.
- Last but not least, this is (for now) only foreseen for IUP. At least port of the functionality is framework agnostic and there are several other frameworks.
- This gives an 'interesting' :o) mix of posibilities, any ideas anyone ?
- - record test events
-
- Start the external event recording/generating tool
- Fire up the GUI
- Start recording
- Perform the required GUI activation, equivalent to one test
- Stop recording and save
- - execute tests
- This depends on the tool used. The best option being that the tool could be started from Lua with, as a command line option, the recording to be replayed. And sync this with the actual test methods.
- Remarks
- - setup (in