Changes

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

I'll be using the 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.

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

     activity = root.find_child(name="HelloWorld Activity",

     activity = root.find_child(name="HelloWorld Activity",

                                       role_name="frame")

                                       role_name="frame")

     toolbox = activity.find_children()[0]

     toolbox = activity.find_children()[0] # we can safely assume that toolbar will be the first element in the Activity UITree

     stop_button = toolbox.find_child(name="StopButton")

     stop_button = toolbox.find_child(name="StopButton")

     assert (stop_button != None)

     assert (stop_button != None)

     assert(result.get_text() == "1")

     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 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. Etoys is not python and doesn't share any code in the UI, so I think it will be out of this project.  

Another complex testing domain we need to care about is network dependent ones. For example to test the chat API's receive method we'd have to actually send in a message from a different chat activity to this one and then test if its working. This isn't a viable approach to test network based triggers. Instead we'd have to mock up the network bits. By that I mean if we have a ChatActivity class that runs the receive method on the "message received" event we'd make a mock class and change the trigger to a manual one.

 

 

 

now this setup method is run at the time of instantiation and it sets the appropriate callback functions to their trigger signals. "self._buddy_joined_cb" is called when a "buddy" joins, self._received_cb is called when we get a message. If I need to test these functions I'd have to generate their signals, which won't be possible without the network. So, another way to test the functions would be to make a mock class where we call self._received_cb with a dummy buddy object and a text message.

 

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 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. Etoys is not python and doesn't share any code in the UI, so I think it will be out of this project.

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