CSC/ECE 517 Spring 2017 E1711 - Revision history

Bzamani at 18:24, 2 April 2017

2017-04-02T18:24:09Z

← Older revision		Revision as of 18:24, 2 April 2017
Line 26:		Line 26:
	Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]		Information about the assignment can be found on [https://docs.google.com/document/d/17f8WVW7i-S5i0HEc__33lDQYRu9RxD7HQndSumQ_-JA/edit#heading=h.kq28lsw1uwf4 this document]

			NOTE: All our changes and updates on the project is committed on the "oss-branch" in our remote git repository, not the "master" branch. [https://github.com/redsock88/expertiza/tree/oss-project]
	==Test Plan==		==Test Plan==

Bzamani: Added some notes about the improvements we made on delayed_mailer_spec.rb test file.

2017-04-01T06:58:39Z

Added some notes about the improvements we made on delayed_mailer_spec.rb test file.

← Older revision		Revision as of 06:58, 1 April 2017
Line 127:		Line 127:
	\|}		\|}

	Our team tried to improve the test file. If you see the delayed_mailer_spec.rb history you notice the test cases were more like just creating a DelayedMailer object and putting that into DelayedJob queue, and then checking if the queue size has increased or not. Well that was a very poor quality test from our perspective because the actual functionality of sending emails per different deadline type was not tested and besides that there ~~was not~~ assignment, topic, user, and etc in the test scenario at all.		Our team tried to improve the test file. If you see the delayed_mailer_spec.rb history, you notice the test cases were more like just creating a DelayedMailer object and putting that into DelayedJob queue, and then checking if the queue size has increased or not. Well..that was a very poor quality test from our perspective, because the actual functionality of sending emails per different deadline type was not tested and besides that, there were no assignment, no topic, no user, and etc in the test scenario at all.
	Now in our test cases we have created all the necessary objects and set their relations to create a fair test environment with an assignment, a topic, team and ~~some users~~, then added test cases which actually test the perform functionality (which is eventually ~~sending~~ emails to ~~target~~ recipients per deadline type). Therefore now we claim our tests cases provide a higher confidence rather than before when they pass.		Now in our test cases we have created all the necessary objects and set their relations to create a fair test environment with an assignment, topic, team and user, then added test cases which actually test the "perform" method functionality (perform method is the major method of DelayedMailer which eventually sends emails to certain recipients per deadline type). Therefore now we claim our tests cases provide a higher confidence rather than before when they pass.

	=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=		=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=

Bzamani: /* Test Plan */

2017-04-01T06:49:50Z

Test Plan

← Older revision		Revision as of 06:49, 1 April 2017
Line 126:		Line 126:
	\| Added		\| Added
	\|}		\|}

			Our team tried to improve the test file. If you see the delayed_mailer_spec.rb history you notice the test cases were more like just creating a DelayedMailer object and putting that into DelayedJob queue, and then checking if the queue size has increased or not. Well that was a very poor quality test from our perspective because the actual functionality of sending emails per different deadline type was not tested and besides that there was not assignment, topic, user, and etc in the test scenario at all.
			Now in our test cases we have created all the necessary objects and set their relations to create a fair test environment with an assignment, a topic, team and some users, then added test cases which actually test the perform functionality (which is eventually sending emails to target recipients per deadline type). Therefore now we claim our tests cases provide a higher confidence rather than before when they pass.

	=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=		=Remove duplicated code between ''delayed_mailer.rb'' and ''scheduled_task.rb''=

Ppraman2: /* Extra Credit */

2017-03-31T22:50:54Z

Extra Credit

← Older revision		Revision as of 22:50, 31 March 2017
Line 211:		Line 211:
	To fix this, we had to add the following code to the private section of late_policies_controller.rb:		To fix this, we had to add the following code to the private section of late_policies_controller.rb:

	def ~~late_policy~~		def late_policy_params
	params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)		params.require(:late_policy).permit(:policy_name, :penalty_per_unit, :penalty_unit, :max_penalty)
	end		end
Line 217:		Line 217:
	and change the argument in the LatePolicy.new() to just		and change the argument in the LatePolicy.new() to just

	@late_policy = LatePolicy.new(~~late_policy~~)		@late_policy = LatePolicy.new(late_policy_params)

	After these two small changes, we were able to create new late policies from the UI.		After these two small changes, we were able to create new late policies from the UI.

Ppraman2: /* Test Plan */

2017-03-31T22:50:30Z

Test Plan

← Older revision		Revision as of 22:50, 31 March 2017
Line 58:		Line 58:
	\| 1		\| 1
	\| Email submission deadline reminders to signed up users		\| Email submission deadline reminders to signed up users
	\| ~~Functional~~		\| Unit
	\| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.		\| A new delayed mailing task is created with deadline type submission deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is submission deadline. Verify the count of mail deliveries increase by 1.
	\| Rspec		\| Rspec
Line 65:		Line 65:
	\| 2		\| 2
	\| Email review deadline reminders to reviewers		\| Email review deadline reminders to reviewers
	\| ~~Functional~~		\| Unit
	\| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.		\| A new delayed mailing task is created with deadline type review deadline . The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is review deadline. Verify the count of mail deliveries increase by 1.
	\| Rspec		\| Rspec
Line 72:		Line 72:
	\| 3		\| 3
	\| Email metareview deadlines to metareviews and team members of the assignment		\| Email metareview deadlines to metareviews and team members of the assignment
	\| ~~Functional~~		\| Unit
	\| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.		\| A new delayed mailing task is created with deadline type metareview deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is metareview deadline. Verify the count of mail deliveries increase by 2. The increase is by 2 instead of 1 like the other tests since both a metareviewer and a team member were emailed.
	\| Rspec		\| Rspec
Line 79:		Line 79:
	\| 4		\| 4
	\| Email drop topic deadline reminders to reviewers		\| Email drop topic deadline reminders to reviewers
	\| ~~Functional~~		\| Unit
	\| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.		\| A new delayed mailing task is created with deadline type drop topic deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.
	\| Rspec		\| Rspec
Line 86:		Line 86:
	\| 5		\| 5
	\| Email sign up deadline reminders to all assignment participants		\| Email sign up deadline reminders to all assignment participants
	\| ~~Functional~~		\| Unit
	\| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.		\| A new delayed mailing task is created with deadline type sign up deadline. The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is drop topic deadline. Verify the count of mail deliveries increase by 1.
	\| Rspec		\| Rspec
Line 93:		Line 93:
	\| 6		\| 6
	\| Email team formation deadline reminders to reviewers		\| Email team formation deadline reminders to reviewers
	\| ~~Functional~~		\| Unit
	\| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.		\| A new delayed mailing task is created. with deadline type team formation deadline The number of delayed jobs pending is increased by 1. One second later, the job launches. Verify that the deadline type of the job is team formation deadline. Verify the count of mail deliveries increase by 1.
	\| Rspec		\| Rspec
Line 107:		Line 107:
	\| 8		\| 8
	\| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.		\| Verify <code>mail_signed_up_users</code> works when there are no sign up topics.
	\| ~~Functional~~		\| Unit
	\| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.		\| New data is inserted into the DB such that there is a single team member on a single assignment with no sign up topics. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email</code>, as expected.
	\| Rspec		\| Rspec
Line 114:		Line 114:
	\| 9		\| 9
	\| Verify <code>mail_signed_up_users</code> works when there are sign up topics.		\| Verify <code>mail_signed_up_users</code> works when there are sign up topics.
	\| ~~Functional~~		\| Unit
	\| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.		\| New data is inserted into the DB such that there is a single team member on a single assignment with a single sign up topic. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that there was a call to <code>find_signed_up_team_members_email_for_all_topics</code>, as expected.
	\| Rspec		\| Rspec
Line 121:		Line 121:
	\| 10		\| 10
	\| Verify <code>find_signed_up_team_members_email</code> works.		\| Verify <code>find_signed_up_team_members_email</code> works.
	\| ~~Functional~~		\| Unit
	\| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.		\| New data is inserted into the DB such that there is a single team member on a single assignment with a no sign up topic whose email address is expertiza@malinator.com. Then a new <code>DelayedMailer</code> object is created. The method is then called and we verify that the found email address is the expertiza@mailinator.com, as expected.
	\| Rspec		\| Rspec

Ppraman2: /* Test Plan */

2017-03-30T23:45:52Z

Test Plan

← Older revision		Revision as of 23:45, 30 March 2017
Line 34:		Line 34:

	[[File:E1711.Slide1.jpg\|frame\|center]]		[[File:E1711.Slide1.jpg\|frame\|center]]
	[[File:~~E1711.~~Slide2.jpg\|frame\|center]]		[[File:Slide2.jpg\|frame\|center]]

Ppraman2: /* Test Plan */

2017-03-30T23:42:22Z

Test Plan

← Older revision		Revision as of 23:42, 30 March 2017
Line 34:		Line 34:

	[[File:E1711.Slide1.jpg\|frame\|center]]		[[File:E1711.Slide1.jpg\|frame\|center]]
	[[File:E1711.~~Slide2r~~.jpg\|frame\|center]]		[[File:E1711.Slide2.jpg\|frame\|center]]

Ppraman2: /* Test Plan */

2017-03-30T23:41:56Z

Test Plan

← Older revision		Revision as of 23:41, 30 March 2017
Line 33:		Line 33:
	The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.		The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.

	[[File:~~Late_Policy_Ruby_Error~~.jpg\|frame\|center]]		[[File:E1711.Slide1.jpg\|frame\|center]]
	[[File:~~Late_Policy_Ruby_Error~~.jpg\|frame\|center]]		[[File:E1711.Slide2r.jpg\|frame\|center]]

Ppraman2: /* Test Plan */

2017-03-30T23:32:46Z

Test Plan

← Older revision		Revision as of 23:32, 30 March 2017
Line 33:		Line 33:
	The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.		The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.

			[[File:Late_Policy_Ruby_Error.jpg\|frame\|center]]
			[[File:Late_Policy_Ruby_Error.jpg\|frame\|center]]

Ppraman2: /* Test Plan */

2017-03-30T23:25:42Z

Test Plan

← Older revision		Revision as of 23:25, 30 March 2017
Line 31:		Line 31:


	~~Note that~~ the ~~recommended format for a test plan included creating a flowchart~~. ~~However, our assignment cannot be easily explained~~ by ~~a flow chart. First, none of the changes impact user behavior (refactoring only)~~. ~~Second, the changes were in an area~~ of the ~~code that was not impacted by user behavior, so there are no decision points that can be made into a flowchart~~.		The following flowchart shows how to arrive at the tested scenarios. The charts refer to Scenarios by number. Below Summary table delves into details of the test cases.