CSC/ECE 517 Spring 2024 - E2439 Testing for view translation substitutor.rb: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Created page with "this one")
 
(Skeleton for our design document. Partially filled, but more to come.)
Line 1: Line 1:
this one
==Problem Statement==
This class is designed to automate substituting text within view templates with translation keys.
The code coverage for this method currently stands at 0%, indicating a need to enhance the test coverage, particularly by focusing on testing edge cases.
According to the existing test file, some methods may be broken. Adopting TDD could be an effective strategy to address and repair these methods.
 
==Team==
===Mentor===
Mustafa Olmez (molmez@ncsu.edu)
 
===Team Members===
Shandler Mason (samason4@ncsu.edu)<br>
Ben Morris (bcmorri4@ncsu.edu)<br>
Ray Wang (rwang32@ncsu.edu)<br>
 
==Issues to be Addressed==
 
* '''Issue #1:'''Determine what view_translation_substitutor.rb does and when it is called.
 
* '''Issue #2:'''Debug and fix substitute()
 
* '''Issue #3:'''Write tests to cover the methods: substitute, process_directory, process_view, and process_translation
 
* '''Issue #4:'''Determine edge cases.
 
* '''Issue #5:'''Write further tests to cover edge cases.
 
==Overview of the Model==
Explain the overall purpose of the model here. Then describe each of the four methods.
 
 
==Plan of work==
We will begin by inserting some debug statements into the model and running expertiza in order to find out when the model runs and what it is accomplishing. Once finished, we will determine what is wrong with the main method of the model, substitute() and fix it. Then we will write tests to have 100% coverage of the model. After that, we will decide what edge cases may arise. Finally, we will write tests to cover the edge cases.
 
Below is a UML diagram already uploaded in Expertiza database documentation for reader reference<br>
INSERT UML DIAGRAM HERE
<!-- [[File:Review mappings imported.png|700px]]<br><br> -->
 
====Design Patterns====
Not sure what to put here. Below is an example from another project.
 
The Code present in review_mapping_helper can be improved by using design patterns to improve maintainability, readability, and flexibility.
Following are some design patterns that are suggested
 
* Methods can be extracted into smaller, well maintained with just a single responsibility. This will promote code readability and promote code reuse.
 
*The methods review_report_data, team_color, obtain_team_color, and others follow a common sequence of steps but allow for variation in some steps. Applying the Template Method Pattern can help define a common structure in a base method while allowing specific steps to be implemented in subclasses or overridden in derived methods.
 
*Descriptive and short naming conventions are required so the methods and variables are self explanatory.
 
* Separation of Concerns should be followed for following code.
 
====Work Plan====
 
I don't know what to put here as we've already mentioned the issues and steps above.
 
==Files Modified==
 
*  app/models/view_translation_substitutor.rb
*  app/spec/models/view_translation_substituto_specr.rb
 
 
==Test Plan==
Testing is currently at 0%. We will first write tests to ensure coverage of each of the four methods in view_translation_substitutor.rb. Then we will add tests to cover the edge cases.
 
<br>The image below shows the test cases are passing as well as most of the code climate issues were resolved.<br>
<!-- [[File:E2353-Test-Report.png|250px]] -->
 
==Github Links==
===Link to Expertiza Repository===
https://github.com/expertiza/expertiza <br>
===Link to Forked Repository===
https://github.com/CSC517-Project4/expertiza <br>
===Link to Pull Request===
ENTER LINK HERE<br>

Revision as of 18:35, 6 April 2024

Problem Statement

This class is designed to automate substituting text within view templates with translation keys. The code coverage for this method currently stands at 0%, indicating a need to enhance the test coverage, particularly by focusing on testing edge cases. According to the existing test file, some methods may be broken. Adopting TDD could be an effective strategy to address and repair these methods.

Team

Mentor

Mustafa Olmez (molmez@ncsu.edu)

Team Members

Shandler Mason (samason4@ncsu.edu)
Ben Morris (bcmorri4@ncsu.edu)
Ray Wang (rwang32@ncsu.edu)

Issues to be Addressed

  • Issue #1:Determine what view_translation_substitutor.rb does and when it is called.
  • Issue #2:Debug and fix substitute()
  • Issue #3:Write tests to cover the methods: substitute, process_directory, process_view, and process_translation
  • Issue #4:Determine edge cases.
  • Issue #5:Write further tests to cover edge cases.

Overview of the Model

Explain the overall purpose of the model here. Then describe each of the four methods.


Plan of work

We will begin by inserting some debug statements into the model and running expertiza in order to find out when the model runs and what it is accomplishing. Once finished, we will determine what is wrong with the main method of the model, substitute() and fix it. Then we will write tests to have 100% coverage of the model. After that, we will decide what edge cases may arise. Finally, we will write tests to cover the edge cases.

Below is a UML diagram already uploaded in Expertiza database documentation for reader reference
INSERT UML DIAGRAM HERE

Design Patterns

Not sure what to put here. Below is an example from another project.

The Code present in review_mapping_helper can be improved by using design patterns to improve maintainability, readability, and flexibility. Following are some design patterns that are suggested

  • Methods can be extracted into smaller, well maintained with just a single responsibility. This will promote code readability and promote code reuse.
  • The methods review_report_data, team_color, obtain_team_color, and others follow a common sequence of steps but allow for variation in some steps. Applying the Template Method Pattern can help define a common structure in a base method while allowing specific steps to be implemented in subclasses or overridden in derived methods.
  • Descriptive and short naming conventions are required so the methods and variables are self explanatory.
  • Separation of Concerns should be followed for following code.

Work Plan

I don't know what to put here as we've already mentioned the issues and steps above.

Files Modified

  • app/models/view_translation_substitutor.rb
  • app/spec/models/view_translation_substituto_specr.rb


Test Plan

Testing is currently at 0%. We will first write tests to ensure coverage of each of the four methods in view_translation_substitutor.rb. Then we will add tests to cover the edge cases.


The image below shows the test cases are passing as well as most of the code climate issues were resolved.

Github Links

Link to Expertiza Repository

https://github.com/expertiza/expertiza

Link to Forked Repository

https://github.com/CSC517-Project4/expertiza

Link to Pull Request

ENTER LINK HERE