Summer of Code/2014/Activity Unit Tests - Revision history

AneeshDogra at 07:59, 20 March 2014

2014-03-20T07:59:13Z

← Older revision		Revision as of 03:59, 20 March 2014
Line 69:		Line 69:
	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.		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.

	~~The~~ UITree sugar3 module uses accessibility information to find UI elements. This information is there for almost all sugar-toolkit elements, but might not be there for elements used by activities. Some activities including Turtle Art would require adding accessibility information before the appropriate tests can be written.		Another issue we need to consider about is that the UITree sugar3 module uses accessibility information to find UI elements. This information is there for almost all sugar-toolkit elements, but might not be there for elements used by activities. Some activities including Turtle Art would require adding accessibility information before the appropriate tests can be written.

	I'd start working on the simpler activities (Read, Write, Calculate) and work my way towards some relatively complex ones (Platipy 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.		I'd start working on the simpler activities (Read, Write, Calculate) and work my way towards some relatively complex ones (Platipy 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.

AneeshDogra at 07:58, 20 March 2014

2014-03-20T07:58:40Z

← Older revision		Revision as of 03:58, 20 March 2014
Line 68:		Line 68:

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

			The UITree sugar3 module uses accessibility information to find UI elements. This information is there for almost all sugar-toolkit elements, but might not be there for elements used by activities. Some activities including Turtle Art would require adding accessibility information before the appropriate tests can be written.

	I'd start working on the simpler activities (Read, Write, Calculate) and work my way towards some relatively complex ones (Platipy 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.		I'd start working on the simpler activities (Read, Write, Calculate) and work my way towards some relatively complex ones (Platipy 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.

AneeshDogra at 19:53, 19 March 2014

2014-03-19T19:53:17Z

← Older revision		Revision as of 15:53, 19 March 2014
Line 23:		Line 23:

	* Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?		* Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?
	As a first time sugar user you see this spiral of activities on home screen. These are the first expression of sugar. These define your experience. Our activities are awesome, they are great and children love it, but we have to make sure they are free of bugs and are consistent. Here's where Activity Unit Tests comes in. We'd have UI and Functionality tests written for each fructose activity to make sure they are in their proper shape. Secondly, tests are important to improve the development process as well. If we have Activity Unit Tests we'd have a more structured and a more easier review process for patches. The maintainers (and I can say this because I am for some of the activities) will have a better time testing the patches they receive from contributors.		As a first time sugar user you see this spiral of activities on the home screen. These are the first expression of sugar. These define your experience. Our activities are awesome, they are great and children love it, but we have to make sure they are free of bugs and are consistent. Here's where Activity Unit Tests comes in. We'd have UI and Functionality tests written for each fructose activity to make sure they are in their proper shape. Secondly, tests are important to improve the development process as well. If we have Activity Unit Tests we'd have a more structured and a more easier review process for patches. The maintainers (and I can say this because I am, for some of the activities) will have a better time testing the patches they receive from contributors.

	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.
Line 69:		Line 69:
	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.		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.		I'd start working on the simpler activities (Read, Write, Calculate) and work my way towards some relatively complex ones (Platipy 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.

AneeshDogra at 19:12, 19 March 2014

2014-03-19T19:12:18Z

← Older revision		Revision as of 15:12, 19 March 2014
Line 30:		Line 30:
	* 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.		* 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:		- 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()		root = uitree.get_root()
Line 41:		Line 41:
	assert (activity_button != None)		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.		- 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.
	one_button = activity_node.find_child(name="1",		one_button = activity_node.find_child(name="1",
	role_name="push button")		role_name="push button")

AneeshDogra at 19:11, 19 March 2014

2014-03-19T19:11:27Z

← Older revision		Revision as of 15:11, 19 March 2014
Line 27:		Line 27:
	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 unittest library for writing unit tests. Its easy to write unittest for functions, that's pretty standard.		* 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.

	~~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:

	* 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()		root = uitree.get_root()
Line 43:		Line 41:
	assert (activity_button != None)		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.		# 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.
	one_button = activity_node.find_child(name="1",		one_button = activity_node.find_child(name="1",
	role_name="push button")		role_name="push button")
Line 52:		Line 50:
	assert(result.get_text() == "1")		assert(result.get_text() == "1")

	Another complex testing domain we need to care about is network dependent ones. For example to test the chat API's UI, we'd have to send in a few messages and check if they are displayed. To invoke the 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. Just run the receive method with some test/dummy data and check if the UI is updated accordingly.		* Another complex testing domain we need to care about is network dependent ones. For example to test the chat API's UI, we'd have to send in a few messages and check if they are displayed. To invoke the 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. Just run the receive method with some test/dummy data and check if the UI is updated accordingly.

	To further explain my approach I'd like to take an example from the Chat Activity. In the chat activity class:		To further explain my approach I'd like to take an example from the Chat Activity. In the chat activity class:

AneeshDogra at 19:09, 19 March 2014

2014-03-19T19:09:42Z

← Older revision		Revision as of 15:09, 19 March 2014
Line 52:		Line 52:
	assert(result.get_text() == "1")		assert(result.get_text() == "1")

	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.		Another complex testing domain we need to care about is network dependent ones. For example to test the chat API's UI, we'd have to send in a few messages and check if they are displayed. To invoke the 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. Just run the receive method with some test/dummy data and check if the UI is updated accordingly.

	To further explain my approach I'd like to take an example from the Chat Activity. In the chat activity class:		To further explain my approach I'd like to take an example from the Chat Activity. In the chat activity class:

AneeshDogra at 19:06, 19 March 2014

2014-03-19T19:06:55Z

← Older revision		Revision as of 15:06, 19 March 2014
Line 27:		Line 27:
	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.
Line 35:		Line 37:
	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)
Line 50:		Line 52:
	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.

			To further explain my approach I'd like to take an example from the Chat Activity. In the chat activity class:

			def _setup(self):
			self.text_channel = TextChannelWrapper(
			self.shared_activity.telepathy_text_chan,
			self.shared_activity.telepathy_conn)
			self.text_channel.set_received_callback(self._received_cb)
			self._alert(_('On-line'), _('Connected'))
			self.shared_activity.connect('buddy-joined', self._buddy_joined_cb)
			self.shared_activity.connect('buddy-left', self._buddy_left_cb)
			self._chat_is_room = True
			self.entry.set_sensitive(True)
			self.entry.grab_focus()
			self._smiley.props.sensitive = True

			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.

Walter: /* Miscellaneous */

2014-03-18T22:36:07Z

Miscellaneous

← Older revision		Revision as of 18:36, 18 March 2014
Line 125:		Line 125:
	* Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?		* Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?
	Well, I am passionate about sugar and that's why I have contributed to the project for some while now. I share the same vision and would love to continue my work in sugar as a part of GSoC.		Well, I am passionate about sugar and that's why I have contributed to the project for some while now. I share the same vision and would love to continue my work in sugar as a part of GSoC.
	~~<pre>~~[[Category:2014 GSoC applications]]~~</pre>~~		[[Category:2014 GSoC applications]]

Godiard: /* You and the community */

2014-03-18T21:19:44Z

You and the community

← Older revision		Revision as of 17:19, 18 March 2014
Line 105:		Line 105:

	Unit testing will give us much better stability and control over changes and it will make it easier to verify other platforms, which is ever more important for us. --[[User:Walter\|Walter]] ([[User talk:Walter\|talk]]) 16:12, 17 March 2014 (EDT)		Unit testing will give us much better stability and control over changes and it will make it easier to verify other platforms, which is ever more important for us. --[[User:Walter\|Walter]] ([[User talk:Walter\|talk]]) 16:12, 17 March 2014 (EDT)

			Would be a good addition have tests for our main activities, and a good start to include them in more activities. --[[User:Godiard\|Godiard]] ([[User talk:Godiard\|talk]]) 17:19, 18 March 2014 (EDT)

	* What will you do if you get stuck on your project and your mentor isn't around?		* What will you do if you get stuck on your project and your mentor isn't around?

AneeshDogra at 20:25, 18 March 2014

2014-03-18T20:25:46Z

← Older revision		Revision as of 16:25, 18 March 2014
Line 50:		Line 50:
	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 ~~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.		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.

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