https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=Apatel13 2026-08-09T04:48:55Z User contributions MediaWiki 1.41.0 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113219 2017-11-14T04:38:04Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd5.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Reference Links==<br /> *[https://github.com/expertiza/expertiza/tree/master/app/views Expertiza Github Master Branch]<br /> *[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format Expertiza Database Schema]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=File:Oodd5.PNG&diff=113218 2017-11-14T04:37:39Z

<p>Apatel13: </p> <hr /> <div></div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113217 2017-11-14T04:36:40Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd4.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Reference Links==<br /> *[https://github.com/expertiza/expertiza/tree/master/app/views Expertiza Github Master Branch]<br /> *[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format Expertiza Database Schema]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=File:Oodd4.PNG&diff=113216 2017-11-14T04:36:19Z

<p>Apatel13: </p> <hr /> <div></div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113215 2017-11-14T04:35:30Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:OODD3.png]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Reference Links==<br /> *[https://github.com/expertiza/expertiza/tree/master/app/views Expertiza Github Master Branch]<br /> *[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format Expertiza Database Schema]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=File:OODD3.png&diff=113214 2017-11-14T04:34:38Z

<p>Apatel13: </p> <hr /> <div></div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113210 2017-11-14T04:24:17Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Reference Links==<br /> *[https://github.com/expertiza/expertiza/tree/master/app/views Expertiza Github Master Branch]<br /> *[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format Expertiza Database Schema]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113209 2017-11-14T04:23:50Z

<p>Apatel13: /* Reference Links */</p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Reference Links==<br /> *[https://github.com/expertiza/expertiza/tree/master/app/views Expertiza Master Branch]<br /> *[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format Expertiza Database Schema]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113208 2017-11-14T04:23:14Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Reference Links==<br /> *[https://github.com/expertiza/expertiza/tree/master/app/views expertiza master branch]<br /> *[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format expertiza schema]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113207 2017-11-14T04:22:46Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Links==<br /> [https://github.com/expertiza/expertiza/tree/master/app/views expertiza master branch]<br /> [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format expertiza schema]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113206 2017-11-14T04:22:18Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Links==<br /> [https://github.com/expertiza/expertiza/tree/master/app/views]<br /> [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2015_E1575_Share_the_data_in_Expertiza_to_a_remote_server_via_PRML_format]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113205 2017-11-14T04:21:51Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Links==<br /> [https://github.com/expertiza/expertiza/tree/master/app/views]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113204 2017-11-14T04:21:42Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==Links==<br /> :·[https://github.com/expertiza/expertiza/tree/master/app/views]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113203 2017-11-14T04:20:15Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==References==<br /> :·[https://github.com/expertiza/expertiza/tree/master/app/views]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113202 2017-11-14T04:19:58Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.<br /> <br /> ==References==<br /> :·[https://github.com/expertiza/expertiza/tree/master/app/views 1]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113200 2017-11-14T04:18:16Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]<br /> <br /> ==Test Plan==<br /> We will be creating test cases in the files <br /> :·peer review.rb :Check with peer reviewer will be able to nominate badges<br /> :·review_assignment_spec.rb:Check whether user is able to review assignment with Team Size=1<br /> :·team_creation_spec.rb:Check the Team Size<br /> :·review_mapping_spec.rb:Check whether reviewer is correctly mapped to the enrolled course<br /> :·Write feature tests to verify the modifications:Include tests in the a new badge_system_spec.rb file in the spec/features directory<br /> <br /> *UI design Testing:<br /> :·Check if peer reviewer is able to nominate for badges with drop down list and contains text boxes for justification.<br /> :·Check if instructor is able to view the summary of all nominations.<br /> :·Cosmetic Inconsistencies – The screen look, feel and design should match the other screens in your application.</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113199 2017-11-14T04:15:26Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design==<br /> [[File:Oodd2.PNG]]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113198 2017-11-14T04:14:49Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]<br /> <br /> ==Design Pattern==<br /> [[File:Oodd2.PNG]]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113197 2017-11-14T04:13:32Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key<br /> <br /> ==Execution Flow==<br /> [[File:Oodd1.PNG]]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=File:Oodd2.PNG&diff=113196 2017-11-14T04:12:20Z

<p>Apatel13: </p> <hr /> <div></div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=File:Oodd1.PNG&diff=113195 2017-11-14T04:12:05Z

<p>Apatel13: </p> <hr /> <div></div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113194 2017-11-14T04:11:09Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Add the code to include the selection of relevant badges and the justification text box Assignment_questionnaire_controller.rb.<br /> :· Add the badges model to assignment_questionnaire.rb.<br /> :· Add the code to display the nomination summary on the page student_task/list page<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113193 2017-11-14T04:09:39Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Provide professors an option to add all possible badges to a project.<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113192 2017-11-14T04:09:08Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Provide professors an option to add all possible badges to a project.<br /> <br /> *Tables to be Modified<br /> :· We’ll be creating a table named “badges”, with the following attributes: <br /> id: primary key<br /> name: varchar<br /> description: varchar<br /> <br /> :· We’ll be creating a table named “assignment_questionnaires_badges”, with the following attributes: <br /> Id: Primary key<br /> assignment_id: foreign key<br /> questionnaire_id: foreign key<br /> badge_id: foreign key</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113189 2017-11-14T04:07:58Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified<br /> :· Provide professors an option to add all possible badges to a project.</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113187 2017-11-14T04:07:40Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.<br /> <br /> ==Modifications To Be Done==<br /> <br /> *Files to be Modified</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/E17AA_Nomination_for_Badges&diff=113183 2017-11-14T04:05:15Z

<p>Apatel13: </p> <hr /> <div>==Problem Statement==<br /> <br /> The purpose of the project is to implement a way to allow students to nominate badges to other students while reviewing their work. The professor should also be able to see the nominations to each student in a single page. <br /> <br /> <br /> ==Pre-Conditions==<br /> <br /> These are the pre-conditions that needs to hold true for each functionality to work<br /> <br /> :· The maximum number of students that can be assigned to the project cannot be more then 1. <br /> :· For students to nominate badges, the professor must have provided a list of pre-decided badges possible for that project. <br /> :· For students to be able to nominate badged without justification only if the project does not have a mandatory justification requirement.<br /> <br /> <br /> ==Implementation Steps==<br /> <br /> :· Provide professors an option to add all possible badges to a project. <br /> :· Allow students to nominate badges while peer reviewing.<br /> :· Show a summary of all nominated badges to professor in a single page.</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017&diff=112823 2017-11-10T21:48:04Z

<p>Apatel13: </p> <hr /> <div>'''Design Project Documentation'''<br /> *[[CSC/ECE 517 Fall 2017/E17A2 Lightweight Badging System]]<br /> *[[CSC/ECE 517 Fall 2017/E17A8. Use a profiler to identify the problems / pages that take some time to load &amp; fix them]]<br /> *[[CSC/ECE 517 Fall 2017/E1793. Help students find teams to join]]<br /> *[[CSC/ECE 517 Fall 2017/E17A4 Allow calibration to be part of an assignment]]<br /> *[[CSC/ECE 517 Fall 2017/E17A0 Team-based reviewing]]<br /> *[[CSC/ECE 517 Fall 2017/E1793. Help students find teams to join_Team1964]]<br /> *[[CSC/ECE 517 Fall 2017/E1791. Track the time that students look at the other submissions - logging improvement]]<br /> *[[CSC/ECE 517 Fall 2017/E1799 Improve self-review Link peer review &amp; self-review to derive grades]]<br /> *[[CSC/ECE_517_Fall_2017/E1797_Timestamps_for_students_submissions]]<br /> *[[CSC/ECE_517_Fall_2017/E17A1|CSC/ECE_517_Fall_2017/E17A1 - Let experts as well as students do reviews]]<br /> *[[CSC/ECE_517_Fall_2017/M1753_OffscreenCanvas]]<br /> *[[CSC/ECE 517 Fall 2017/M1754_Mutation_Testing]]<br /> *[[CSC/ECE 517 Fall 2017/E1794. Student-generated questions added to rubric]]<br /> *[[CSC/ECE 517 Fall 2017/E17A6. Fix account creation over web to work reasonably]]<br /> *[[CSC/ECE 517 Fall 2017/E1792 OSS Visualizations for instructors]]<br /> *[[CSC/ECE 517 Fall 2017/E17A4 Allow calibration to be part of an assignment_Team34]]<br /> *[[CSC/ECE 517 Fall 2017/E17A7_Allow_Reviewers_to_bid_on_what_to_review]]<br /> *[[CSC/ECE 517 Fall 2017/E17A9 Lazy loading (infinite scroll) for assignments courses questionnaires and user lists with Jscroll]]<br /> *[[CSC/ECE 517 Fall 2017/E1796. Unify Create Assignment and Edit Assignment pages]]<br /> *[[CSC/ECE 517 Fall 2017/E17A5 Allow users to create an account and submit work to an &quot;assignment&quot; (e.g., for conference reviewing)]]<br /> *[[CSC/ECE 517 Fall 2017/E17A3 Upgrade review input UI and sanitize text input]]<br /> *[[CSC/ECE 517 Fall 2017/E17AA Nomination for Badges]]<br /> <br /> <br /> '''Writing Assignment 2'''<br /> *[[CSC/ECE 517 Fall 2017/E1779. Fix teammate advertisements and requests to join a team]]<br /> *[[CSC/ECE_517_Fall_2017/E1773 Investigate and Fix Expertiza Production Version Runtime Exceptions.rb]]<br /> *[[CSC/ECE_517_Fall_2017/E1774 Metareview fixes and improvements.rb]]<br /> *[[CSC/ECE_517_Fall_2017/E1788 OSS project Maroon Heatmap fixes]]<br /> *[[CSC/ECE 517 Fall 2017/E1781 Topic Management]]<br /> *[[CSC/ECE_517_Fall_2017/E1745_Refactor_response_controller.rb]]<br /> *[[CSC/ECE_517_Fall_2017/E1752 Refactor assignments controller]]<br /> *[[CSC/ECE_517_Fall_2017/E1776_Enhance_Imports]]<br /> *[[CSC/ECE_517_Fall_2017/E1756 TLD Refactor response.rb]]<br /> *[[CSC/ECE_517_Fall_2017/E1772_Refactor reputation_web_service_controller.rb]]<br /> *[[CSC/ECE_517_Fall_2017/M1753_OffscreenCanvas API]]<br /> *[[CSC/ECE_517_Fall_2017/M1754_Mutation Testing on Servo]]<br /> *[[CSC/ECE_517_Fall_2017/E1753 OSS project bidding tests]]<br /> *[[CSC/ECE_517_Fall_2017/E1766_Test team functionality]]<br /> *[[CSC/ECE 517 Fall 2017/E1767 Improve imports]]<br /> *[[CSC/ECE_517_Fall_2017/E1786_OSS project Juniper Bookmark Enhancements]]<br /> *[[CSC/ECE_517_Fall_2017/E1787_OSS project Bronze Score calculations]]<br /> *[[CSC/ECE_517_Fall_2017/E1763 Fix Staggered-Deadline Assignments]]<br /> *[[CSC/ECE 517 Fall 2017/E1757 Introduce a Student View for instructors]]<br /> *[[CSC/ECE 517 Fall 2017/E1769_Refactor assignment_form.rb]]<br /> *[[CSC/ECE 517 Fall 2017/E1754_Feature_test_of_rubric_advice]]<br /> *[[CSC/ECE 517 Fall 2017/E1782 OSS Project Red Assignment Directories]]<br /> *[[CSC/ECE 517 Fall 2017/E1748 Add past-due assignments to task list]]<br /> *[[CSC/ECE 517 Fall 2017/E1761 Test First Development Refactor assignment.rb]]<br /> *[[CSC/ECE_517_Fall_2017/E1780_OSS_Project_Teal_Email_Notification_Enhancements]]<br /> *[[CSC/ECE_517_Fall_2017/E1762 Test various kinds of response-map hierarchies]]<br /> *[[CSC/ECE_517_Fall_2017/E1759 ]]<br /> *[[CSC/ECE_517_Fall_2017/E1749_Test First Development Refactor questionnaire_controller.rb]]<br /> *[[CSC/ECE 517 Fall 2017/E1777 Coherent specification of review requirements.rb]]<br /> *[[CSC/ECE 517 Fall 2017/E1771_Refactor_team.rb]]<br /> *[[CSC/ECE 517 Fall 2017/E1784 Fix mass assignments reported by Brakeman.rb]]</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111090 2017-11-01T00:15:10Z

<p>Apatel13: /* Challenges */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A:<br /> <br /> Setting up the environment for Mac OS-Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B:<br /> Build Process and Invoking Script<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * Mutation test can be ran using the following command from the servo directory:<br /> <br /> cd servo<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> *There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111089 2017-11-01T00:14:31Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A:<br /> <br /> Setting up the environment for Mac OS-Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B:<br /> Build Process and Invoking Script<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * Mutation test can be ran using the following command from the servo directory:<br /> <br /> cd servo<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111088 2017-11-01T00:13:09Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A:<br /> <br /> Setting up the environment for Mac OS-Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B:<br /> Build Process and Invoking Script<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * Mutation test can be ran using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111087 2017-11-01T00:12:39Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A:<br /> Setting up the environment for Mac OS: <br /> Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B:<br /> Build Process and Invoking Script<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * Mutation test can be ran using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111086 2017-11-01T00:12:12Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A-Setting up the environment for Mac OS: <br /> Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B-Build Process and Invoking Script<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * Mutation test can be ran using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111085 2017-11-01T00:11:30Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A-Setting up the environment for Mac OS: <br /> Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B-Build Process and Invoking Script<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * Mutation test can be ran using the following command from the servo directory:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111084 2017-11-01T00:11:13Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A-Setting up the environment for Mac OS: <br /> Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B-Build Process<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * Mutation test can be ran using the following command from the servo directory:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111083 2017-11-01T00:09:53Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A-Setting up the environment for Mac OS: <br /> Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B-Build Process<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * From the Servo directory invoke the following script :<br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> Mutation test can be ran using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111082 2017-11-01T00:08:50Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A-Setting up the environment for Mac OS: <br /> Install python version 3 and run the following for installation of virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> <br /> Step B-Build Process<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * From the Servo directory invoke the following script :<br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111081 2017-11-01T00:08:32Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A-Setting up the environment for Mac OS: <br /> Install python version 3 and run the following for installation virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> <br /> Step B-Build Process<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * From the Servo directory invoke the following script :<br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111080 2017-11-01T00:08:04Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> <br /> Step A-Setting up the environment for Mac OS: Install python version 3 and run the following for installation virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> <br /> Step B-Build Process<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * From the Servo directory invoke the following script :<br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111079 2017-11-01T00:07:44Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link].<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> Step A-Setting up the environment for Mac OS: Install python version 3 and run the following for installation virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> <br /> Step B-Build Process<br /> * Clone the repository from [https://github.com/dsandeephegde/servo link]<br /> <br /> * From the Servo directory invoke the following script :<br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111078 2017-11-01T00:05:10Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> Step A-Setting up the environment for Mac OS: Install python version 3 and run the following for installation virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> <br /> Step B-Build Process<br /> * Clone the repository [https://github.com/dsandeephegde/servo]<br /> * From the Servo directory invoke the <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111077 2017-11-01T00:04:30Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description.<br /> <br /> Example on how to setup the environment and run the mutation testing scripts.<br /> Step A-Setting up the environment for Mac OS: Install python version 3 and run the following for installation virtualenv: <br /> <br /> sudo port install python27 py27-virtualenv cmake yasm<br /> <br /> Step B-Build Process<br /> * Clone the repository [https://github.com/dsandeephegde/servo]<br /> * From the Servo directory invoke the <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111076 2017-10-31T23:38:56Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and run tests on them to check for failures. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> There are standard techniques that define what a mutant is. For example, replacing '&amp;&amp;' with '||'. However, there is no specification for the number of replacements that must be made within a single source code, nor is there any specification on the permutations of possible mutations for each technique. This is an ambiguity in the project and our implementation replaces all instances of '&amp;&amp;' to '||' to generate a single type of mutant for the each file of the source code.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=111075 2017-10-31T23:32:32Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base. <br /> <br /> The implementation of this project was done by writing python scripts that would modify the source code to generate mutants and test them. The scripts would temporarily modify the source codes, call the corresponding tests and revert back to the original code by reversing the changes that were made earlier. This process was repeated for multiple iterations by modifying various parts of the source code.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. It is expected that any reviewer will face a similar challenge.<br /> <br /> We overcame this challenge by discussing possibilities with Mozilla team who suggested us to use web application such as Janitor Technology. Using a web based platform for our testing made the project agnostic of the environment on the local machine and any hassle associated with same.<br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. Due to a large number of source files and WPT tests for the entire project, it was difficult for one individual to have information on the mapping of components to their corresponding WPTs. <br /> <br /> Hence, we had to have a mapping to run the corresponding tests for a source file. The mapping framework enabled us to run tests on a few components and provide a base for other members from Mozilla team to add and replicate the same framework as per their requirement.<br /> <br /> 3. Understanding the extent of mutation testing to be performed.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=110987 2017-10-30T05:46:07Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The project is about writing a python script to change the source code and run tests. It does not add any functionality to Servo. So there is no scope for testing in this project.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. <br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. We had to have a mapping to be able to run the corresponding tests for a source file.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=110986 2017-10-30T04:08:25Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. <br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. We had to have a mapping to be able to run the corresponding tests for a source file.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=110972 2017-10-30T03:42:39Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Web-platform-tests===<br /> The web-platform-tests Project is a W3C-coordinated attempt to build a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn, gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as a Fault-based testing strategy as it involves creating faults in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/script/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Testing===<br /> <br /> The script for mutation testing is tested by creating mutants and validating the performance of WPT on the mutants.<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. <br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. We had to have a mapping to be able to run the corresponding tests for a source file.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=110782 2017-10-28T04:17:07Z

<p>Apatel13: /* Execution */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as Fault based testing strategy as it involves creating fault in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be invoked by using the following command:<br /> <br /> python python/servo/mutation/init.py components/scirpt/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. <br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. We had to have a mapping to be able to run the corresponding tests for a source file.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=110781 2017-10-28T04:14:31Z

<p>Apatel13: </p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as Fault based testing strategy as it involves creating fault in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> Mutation test can be started by using the following command:<br /> <br /> python python/servo/mutation/init.py components/scirpt/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. <br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. We had to have a mapping to be able to run the corresponding tests for a source file.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2017/M1754_Mutation_Testing_on_Servo&diff=110780 2017-10-28T04:13:51Z

<p>Apatel13: /* Challenges */</p> <hr /> <div>Servo uses the Web Platform Test (WPT) suite for testing, but does not perform an evaluation of the breadth of the tests. The goal of this project is to use techniques from mutation testing to evaluate the performance of the WPT suite when bugs are deliberately introduced into the code base.<br /> <br /> ==Introduction==<br /> <br /> ===Servo===<br /> <br /> Servo is a modern, high-performance browser engine designed for both application and embedded use. [https://servo.org Servo] is a web browser layout engine written in [https://github.com/rust-lang/rust Rust]and is currently being developed by [https://en.wikipedia.org/wiki/Mozilla Mozilla]. The aim of the project is not to create a full browser but is rather to create a highly parallel environment that allows for many components be handled by fine-grained, isolated tasks. [https://en.wikipedia.org/wiki/Servo_(layout_engine)]<br /> <br /> ===Rust===<br /> <br /> [https://doc.rust-lang.org/book/second-edition/ Rust] is an open source, systems programming language sponsored by Mozilla Research. Rust performs the majority of its safety checks and memory management decisions at compile time, so that program’s runtime performance is not impacted. Making it useful in programs with predictable space and time requirements, embedding in other languages, and writing low-level code, like device drivers and operating systems.<br /> <br /> ===Mutation Testing===<br /> Mutation Testing is a type of software testing where we mutate (change) certain statements in the source code and check if the test cases are able to find the errors.The goal of Mutation Testing is to assess the quality of the test cases which should be robust enough to fail mutant code. This method is also called as Fault based testing strategy as it involves creating fault in the program.Faults are introduced into the source code of the program by creating many versions called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant version to fail which demonstrates the effectiveness of the test cases.[https://www.guru99.com/mutation-testing.html ]<br /> <br /> =='''Project description'''==<br /> ===Build process===<br /> * The steps to setup the environment were followed as mentioned in readme file [https://github.com/servo/servo link]. The servo code was built in release mode on a Mac environment using the below command:<br /> <br /> ./mach build --release<br /> <br /> The whole set of WPT was run on the servo code base using the below command:<br /> <br /> ./mach test -wpt --release<br /> <br /> ===Implemented steps===<br /> The approach adopted was based on the requirements mentioned [https://github.com/servo/servo/wiki/Mutation-testing-project here]. The below steps implement the initial steps mentioned in the project description. <br /> <br /> * Step 1: A python script was written to mutate one source file and the corresponding WPT was run on it to check if the mutant was killed.<br /> <br /> * Step 2: A test framework was defined to identify the source files that require mutation testing along with their corresponding WPTs. This framework is implemented in /servo/components/script/dom.<br /> <br /> * Step 3: The script was expanded to include the test framework and automate the process of generating mutations for multiple source files and running their corresponding WPTs based on the test_mapping.json. The script also traverses through sub folders of the parsed path to check for the .json file. The script also logs on the terminal any mutants that the WPT failed to kill.<br /> <br /> * Step 4: Integrated the script so that it can be invoked from the CI tool.<br /> <br /> ===Execution===<br /> <br /> The script can be called by running in terminal: <br /> <br /> python python/servo/mutation/init.py components/scirpt/dom<br /> <br /> ===Output===<br /> <br /> The log for success to kill a mutant is as shown below:<br /> <br /> [[File:Oss4.png]]<br /> <br /> The log for failure to kill a mutant is as shown below:<br /> <br /> [[File:Oss1.png]]<br /> <br /> ===Subsequent steps===<br /> <br /> The following subsequent steps will be followed to meet the project requirements as per this [https://github.com/servo/servo/wiki/Mutation-testing-project].<br /> <br /> * implement mutations like replacing if statements by if true/if false, duplicating statements, reordering statements, changing arithmetic &amp; atomic string constant.<br /> * improving the performance of the testing, for example randomizing the test order, fast-failing, running tests with faster builds (e.g. ./mach build -d).<br /> * find heuristics for identifying false positives, that is mutations which are expected to have no effect, for example removing logging.<br /> * find search heuristics for identifying mutations that cause no test failures.<br /> <br /> ===Challenges===<br /> <br /> 1. Setting up environment in local machine:<br /> <br /> *The amount of time taken to build and test the WPT in local machine was pretty long due to machine memory. Additionally faced problems on intermittent WPT test failures. <br /> <br /> 2. Defining the test mapping framework:<br /> <br /> *Servo consists of multiple components of which there are many wpt tests written for each component. The test cases are organized according to the functionality they test, whereas the servo source code is organized according to the specific components. We had to have a mapping to be able to run the corresponding tests for a source file.<br /> <br /> ==Pull Request==<br /> <br /> Here is our pull request [https://github.com/servo/servo/pull/18984 link]. <br /> <br /> ==References==<br /> &lt;references/&gt;<br /> 1. https://en.wikipedia.org/wiki/Servo_(layout_engine)&lt;br&gt;<br /> 2. https://www.guru99.com/mutation-testing.html&lt;br&gt;<br /> 3. https://github.com/servo/servo&lt;br&gt;<br /> 4. https://github.com/servo/servo/wiki/Mutation-testing-project&lt;br&gt;</div>

Apatel13