CSC/ECE 517 Spring 2016/E1738 Integrate Simicheck Web Service - Revision history

Djgutier: /* Automated Testing within Rails */

2017-05-04T06:19:14Z

Automated Testing within Rails

← Older revision		Revision as of 06:19, 4 May 2017
Line 105:		Line 105:
	The test for HttpRequest checks that it will accept all possible valid URLs (exceptions like unresolved IP addresses are noted in a comment), since this static method is used by the fetchers to only accept valid URLs. Its get method to start and process a GET request is not unit tested since that is a wrapper for the Net::HTTP::Get.		The test for HttpRequest checks that it will accept all possible valid URLs (exceptions like unresolved IP addresses are noted in a comment), since this static method is used by the fetchers to only accept valid URLs. Its get method to start and process a GET request is not unit tested since that is a wrapper for the Net::HTTP::Get.

	Lastly a unit test is provided for the Simicheck webservice to ensure that the logic we added to handle the API works. There is a delay during the testing of 30 seconds to prevent bombarding their servers with requests, also because the comparisons are not instantaneous. Essentially the test creates a comparison and runs it through the methods used to interact with the Simicheck REST API to ensure that it still works. One caveat is that a network connection is required.		Lastly a unit test is provided for the Simicheck webservice to ensure that the logic we added to handle the API works. There is a delay during the testing of 30 seconds to prevent bombarding their servers with requests, also because the comparisons are not instantaneous. Essentially the test creates a comparison and runs it through the methods used to interact with the Simicheck REST API to ensure that it still works. One caveat is that a network connection is required which could lead to a false failure.

	All of the above unit tests here can be improved by using a gem that is designed for testing external APIs, like VCR for example, that will mock out low level calls to Net::HTTP::Get, etc, and can replay API responses. This is the best long term solution, however was not implemented in order to not break compatibility with the existing toolchain versions by adding another gem.		All of the above unit tests here can be improved by using a gem that is designed for testing external APIs, like VCR for example, that will mock out low level calls to Net::HTTP::Get, etc, and can replay API responses. This is the best long term solution, however was not implemented in order to not break compatibility with the existing toolchain versions by adding another gem. A high level test using Capybara could also be added to click through the UI and using the factories to create test data as submissions, but there are many complexities to consider there and we opted not to implement here until an API testing gem would be added to the code to replay API responses and calls.

Djgutier: /* Automated Testing within Rails */

2017-05-04T06:16:48Z

Automated Testing within Rails

@@ Line 98: / Line 98: @@
 *spec/models/google_doc_fetcher_spec.rb
 *spec/models/http_request_spec.rb
 *spec/models/simicheck_webservice_spec.rb
 *spec/models/submission_content_fetcher_spec.rb

Nlgrant: /* Automated Testing within Rails */

2017-04-30T03:59:10Z

Automated Testing within Rails

← Older revision		Revision as of 03:59, 30 April 2017
Line 96:		Line 96:
	We wrote unit tests for the new functionality that we implemented, this included models, helpers, SimiCheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:		We wrote unit tests for the new functionality that we implemented, this included models, helpers, SimiCheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:
	*spec/models/website_fetcher_spec.rb		*spec/models/website_fetcher_spec.rb
			*spec/models/google_doc_fetcher_spec.rb
			*spec/models/http_request_spec.rb
			*spec/models/plagiarism_checker_assignment_submission_spec.rb
			*spec/models/plagiarism_checker_comparison_spec.rb
			*spec/models/simicheck_webservice_spec.rb
			*spec/models/submission_content_fetcher_spec.rb

Eleill: /* Automated Testing within Rails */

2017-04-30T03:55:06Z

Automated Testing within Rails

← Older revision		Revision as of 03:55, 30 April 2017
Line 95:		Line 95:
	=== Automated Testing within Rails ===		=== Automated Testing within Rails ===
	We wrote unit tests for the new functionality that we implemented, this included models, helpers, SimiCheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:		We wrote unit tests for the new functionality that we implemented, this included models, helpers, SimiCheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:
	~~<br>~~spec/models/website_fetcher_spec.rb		*spec/models/website_fetcher_spec.rb

Eleill: /* Testing Strategy */

2017-04-30T03:51:25Z

Testing Strategy

← Older revision		Revision as of 03:51, 30 April 2017
Line 94:		Line 94:
	== Testing Strategy ==		== Testing Strategy ==
	=== Automated Testing within Rails ===		=== Automated Testing within Rails ===
	We wrote unit tests for the new functionality that we implemented, this included models, helpers, ~~simicheck~~ logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:		We wrote unit tests for the new functionality that we implemented, this included models, helpers, SimiCheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:
	<br>spec/models/website_fetcher_spec.rb		<br>spec/models/website_fetcher_spec.rb

Eleill: /* User Interface */

2017-04-30T03:51:01Z

User Interface

← Older revision		Revision as of 03:51, 30 April 2017
Line 76:		Line 76:


	To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click "New public/private assignment". The last two fields on the New Assignment page say "SimiCheck Delay" and "SimiCheck Similarity Threshold". In "~~Simicheck~~ Delay", select a value between 0 and 100 to enable the Plagiarism Checker. In "SimiCheck Similarity Threshold", select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents.		To view the interface changes, login to Expertiza as an instructor; navigate to Manage... Assignments. Click "New public/private assignment". The last two fields on the New Assignment page say "SimiCheck Delay" and "SimiCheck Similarity Threshold". In "SimiCheck Delay", select a value between 0 and 100 to enable the Plagiarism Checker. In "SimiCheck Similarity Threshold", select a percentage value to filter the Plagiarism Checker Comparison results. The percentage refers to the percent of same text between two documents.

	After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the "View review report" icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select "Plagiarism Checker Report" from the select box, and click "Submit". If there is any plagiarism to report, it will load.		After the assignment ends and the delay period has passed, you can view the Plagiarism Report. Click the "View review report" icon containing a magnifying glass and two people (in the third row of per-assignment icons). Select "Plagiarism Checker Report" from the select box, and click "Submit". If there is any plagiarism to report, it will load.

Eleill: /* API Testing during Development */

2017-04-30T03:50:33Z

API Testing during Development

← Older revision		Revision as of 03:50, 30 April 2017
Line 93:		Line 93:

	== Testing Strategy ==		== Testing Strategy ==
	~~=== API Testing during Development ===~~
	API testing can be done outside of our code using applications like [https://www.getpostman.com/ Postman]. We will use this to determine which API calls to use and what our expected output will be. In addition, this will lay the groundwork for testing within Rails for the direct API calls that the Expertiza server will do.

	=== Automated Testing within Rails ===		=== Automated Testing within Rails ===
	We wrote unit tests for the new functionality that we implemented, this included models, helpers, simicheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:		We wrote unit tests for the new functionality that we implemented, this included models, helpers, simicheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:
	<br>spec/models/website_fetcher_spec.rb		<br>spec/models/website_fetcher_spec.rb

Nlgrant: /* Testing Strategy */

2017-04-30T03:48:48Z

Testing Strategy

← Older revision		Revision as of 03:48, 30 April 2017
Line 97:		Line 97:

	=== Automated Testing within Rails ===		=== Automated Testing within Rails ===
	We ~~plan on writing~~ unit tests for ~~any controllers and models~~ that we ~~create. High level testing of the controllers~~, models, ~~and view together will be done with Capybara~~. ~~The tests~~ we ~~write will be alongside~~ the ~~existing~~ test ~~framework~~ in ~~Expertiza~~.		We wrote unit tests for the new functionality that we implemented, this included models, helpers, simicheck logic etc.. In order to properly unit test we mocked all interfaces and black box tested the new functionality. Our test cases can be found in the following locations:
			<br>spec/models/website_fetcher_spec.rb

Eleill: /* Diagrams */

2017-04-30T03:45:34Z

Diagrams

← Older revision		Revision as of 03:45, 30 April 2017
Line 63:		Line 63:
	<br>		<br>
	[[File:Simicheck_API_-_SimiCheck.png]]		[[File:Simicheck_API_-_SimiCheck.png]]
			<br>
	Class heirarchy in the fetchers:		Class heirarchy in the fetchers:
			<br>
	[[File:SimiCheck_Fetchers.png]]		[[File:SimiCheck_Fetchers.png]]

Eleill: /* Diagram */

2017-04-30T03:45:11Z

Diagram

← Older revision		Revision as of 03:45, 30 April 2017
Line 59:		Line 59:
	This model '''has_many''' PlagiarismCheckerComparison models. It represents the results of the comparison among submissions for the assignment. As such it will contain all of the relevant fields that are shown in the view as described in the requirements.		This model '''has_many''' PlagiarismCheckerComparison models. It represents the results of the comparison among submissions for the assignment. As such it will contain all of the relevant fields that are shown in the view as described in the requirements.

	=== ~~Diagram~~ ===		=== Diagrams ===
	Typical overall system operation ~~is shown here~~:		Typical overall system operation:
	<br>		<br>
	[[File:Simicheck_API_-_SimiCheck.png]]		[[File:Simicheck_API_-_SimiCheck.png]]

			Class heirarchy in the fetchers:
			[[File:SimiCheck_Fetchers.png]]

	=== User Interface ===		=== User Interface ===