build-test-deploy Development Environment

BTD

• Home
  • Overview
  • Status
  • Download
  • Dependencies
  • History
  • Credits
  • Contact us
• Manual
  • Installing
  • Introduction
  • Why use BTD ?
  • Using BTD
  • Unit test
    • Test.lua
    • TestApi.lua
    • jEdit integration
  • GUI test
• Reference
• Project
  • Bug Tracker
  • CVS - not yet operative
• License

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 and iup.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 the iup.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 way testIup.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 returns iup.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 returns iup.CLOSE

- 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)

But this faces different problems :

• 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 ?

The best solution, for the time being, is to use an 'aplication automation' tool as there are several for different windowing environments. For example :

- 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

This should be repeated for all tests.

- 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.