CSC/ECE 517 Spring 2024 - E2439 Testing for view translation substitutor.rb

E2439 Testing for view translation substitutor.rb

This wiki page is for the description of changes made in Spring 2024, CSC/ECE 517 for the E2439 Testing for view translation substitutor.rb assignment.

Expertiza

Expertiza is an open source software project (OSS) using Ruby on Rails framework. Expertiza is led by Dr. Edward Gehringer. Expertiza allows students to create different teams and work on various assignments and projects. Also, students have the capability to peer review and evaluate each other's work. In Expertiza, instructors have the ability to create new assignments and edit already existing projects. The instructor can use a filter to narrow a list of subjects for students. Expertiza allows submissions from PDFs, wiki pages and URLs document types.

Project Objective

This class (view_translation_substitutor.rb) is designed to automate substituting text within view templates with translation keys. Our objective is to create tests to cover various edge cases. Also, we must add detailed explanations for all the tests.

Problem Statement

The code coverage for view_translation_substitutor.rb 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.

Tasks

• Task #1: Determine what view_translation_substitutor.rb does and when it is called.

• Task #2: Debug and fix substitute()

• Task #3: Write tests to cover the methods: substitute, process_directory, process_view, and process_translation

• Task #4: Write further tests to cover edge cases.

Model Overview & Test Implementation

The ViewTranslationSubstitutor class is designed to assist in the internationalization process of applications by substituting hardcoded text strings in view templates with dynamic translation calls. It processes a given locale hash, iterates through directories and view files, and replaces identified strings with translations from the locale hash. Additionally, it generates statistics regarding the substitutions made during the process.

Method Summaries:

substitute(locale)

Description: Processes the given locale hash by iterating through directories and view files, replacing hardcoded strings with translations, and generating statistics. Parameters: locale: A hash containing translation data organized by directory and view name.

Returns: None

Use Cases

1. When it is a developer, the model will replace hardcoded strings with translated versions.
2. When it is a developer, Expertiza's content will always up-to-date with the latest translations.

Edge Cases

1. When translation files are located within nested directories, all directories should be recursively traverse to ensure that no translations are missed.
2. When there are various file types (JSON, YAML, or plain text files), it should handle different file formats and parsing methods.

process_directory(dir_name, view_hash)

Description: Processes a directory within the application, iterating through view files and replacing hardcoded strings with translations. Parameters: dir_name: Name of the directory being processed. view_hash: Hash containing translation data for views within the directory.

Returns: A hash containing statistics for each view within the directory.

Use Cases

1. When it is a developer, they ensure consistent handling of translations across different parts of Expertiza.
2. When it is a developer, the model can be integrated into workflows that utilize TMS platforms for managing translations.

Edge Cases

1. When the model encounters directories or files with restricted permissions or inaccessible locations, there must be proper error handling.

process_view(directory_name, view_name, translations)

Description: Processes a specific view file, replacing hardcoded strings with translations and updating the file accordingly. Parameters: directory_name: Name of the directory containing the view file. view_name: Name of the view file. translations: Hash containing translation data for the specific view.

Returns: A hash containing statistics for the translations made in the view file.

Use Cases

1. When it is a developer, the model localizes static text elements while preserving dynamic content.
2. When it is a developer, the model will update view files with specific messaging and translations.

Edge Cases

1. When the translations parameter is empty or contains no translations for the specified view file.
2. When the view file contains ambiguous strings that may have multiple possible translations.

process_translation(contents, key, val)

Description: Processes translations within the contents of a view file, replacing hardcoded strings with dynamic translation calls. Parameters: contents: Contents of the view file as a string. key: Key representing the translation key. val: Value representing the translation text.

Returns: A tuple containing a hash of statistics for the translations made and the updated contents of the view file.

Use Cases

1. When it is a developer, they will leverage the model to incorporate accessibility-focused translations and alternative text descriptions into view files for images, buttons, and other interactive elements.
2. When it is a marketer, they will implement A/B test variations by dynamically swapping out hardcoded strings with alternative translations.

Edge Cases

1. When the contents parameter contains invalid markup, preventing proper parsing of the view file.
2. When the view file contains complex HTML structure with nested elements and dynamic content.

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 & Principles

Single Responsibility Principle (SRP):

• Each test case has a single responsibility and focuses on a specific aspect of the application.
• The different types of tests (unit, integration, and system) are separated in order to improve clarity and organization.

Don't Repeat Yourself Principle (DRY):

• Setup and cleanup steps for all tests are the same and thus, are combined together.

Open/Closed Principle (OCP):

• Test classes are designed so that they are open for extension. New tests can be added without needing to modify the existing test code.

Singleton Pattern:

• There is only a single setup that is shared for all of the test cases that need to use it.

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.

Demo Video

INSERT VIDEO HERE

Using RSpec

We implemented tests which offers 100% coverage for the view_translation_substitutor.rb.

How to See Test Coverage

Run RSpec for view_translation_substitutor.rb, sudo su, yum install lynx, then lynx ./coverage/index.html. We chose to use Lynx because it displays the test coverage in an easy and readable way.

Results

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

view_translation_substitutor.rb model coverage = 100%

INSERT IMAGE HERE

Future Work

To be determined after project completion.

Team

Mentor

Mustafa Olmez (molmez@ncsu.edu)

Team Members

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

References

1. Expertiza GitHub
2. Project Repository
3. Github Project Board
4. [LINK Pull Request]
5. RSpec