33
edits
Changes
Jump to navigation
Jump to search
Line 27:
Line 27: − + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Summer of Code/2014/Activity Unit Tests (view source)
Revision as of 15:50, 18 March 2014
, 15:50, 18 March 2014no edit summary
The project doesn't end here. As activities are diverse these will serve as good examples for other activities. They'll serve as guides for porting of existing and new activities. I'd also document my findings and write a wiki page on how to write tests for activities (with some examples), so that it can serve as a guide for new activity authors.
The project doesn't end here. As activities are diverse these will serve as good examples for other activities. They'll serve as guides for porting of existing and new activities. I'd also document my findings and write a wiki page on how to write tests for activities (with some examples), so that it can serve as a guide for new activity authors.
I'll be using the python unittest library for writing unit tests. Its easy to write unittest for functions, that's pretty normal. Testing the GUI is a bit complex, the initial strategy is to simulate GUI triggers, like a mouse click, key down event etc. That's it for the technicalities of the project. I'd start working on the simpler activities (Read, Write, Calculate) and work my way towards some relatively complex ones (Etoys and TurtleArt). I figure Etoys and Turtle Art would take the most of the time, so I'd try to complete everything else and start on TurtleArt before the mid-evaluation week.
I'll be using the python unittest library for writing unit tests. Its easy to write unittest for functions, that's pretty standard. Testing the GUI is a bit complex, the initial strategy is to simulate GUI triggers, like a mouse click, key down event etc using the uitree module in the sugar3 toolkit.
- The initial GUI tests would be to check if all the buttons in the toolbar exists, and buttons and other elements on the screen/canvas exists as they are expected to.
Basic structure of the code would look like:
root = uitree.get_root()
activity = root.find_child(name="HelloWorld Activity",
role_name="frame")
toolbox = activity.find_children()[0]
stop_button = toolbox.find_child(name="StopButton")
assert (stop_button != None)
activity_button = toolbox.find_child(name="ActivityButton")
assert (activity_button != None)
- The second stage would be to test if the buttons work as expected, we'd get the button reference using the uitree module and use the do_action method to run that particular action.
An example from the calculate activity, there is a
one_button = activity_node.find_child(name="1",
role_name="push button")
one_button.do_action("click")
# check if 1 is entered in the text box
result = activity.find_child(name="", role_name="text")
assert(result.get_text() == "1")
That's it for the technicalities of the project. I'd start working on the simpler activities (Read, Write, Calculate) and work my way towards some relatively complex ones (Etoys and TurtleArt). I figure Etoys and Turtle Art would take the most of the time, so I'd try to complete everything else and start on TurtleArt before the mid-evaluation week.
* What is the timeline for development of your project? The Summer of Code work period is from May 19 - August 22; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (27 June); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.
* What is the timeline for development of your project? The Summer of Code work period is from May 19 - August 22; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (27 June); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.