feat: Add support for the new Pre-Translate Efficiency Report

[jameskim0987]

Resolves #57

Changes made in this PR:

1. add PreTranslateEfficiencySchema struct and its respective ValidateSchema()
2. add const ReportPreTranslateEfficiency
3. add valid testcase for PreTranslateEfficiencySchema.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.17%. Comparing base (3ec8c35) to head (7ded699).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #65      +/-   ##
==========================================
- Coverage   98.20%   98.17%   -0.02%     
==========================================
  Files          66       66              
  Lines        2934     2944      +10     
==========================================
+ Hits         2881     2890       +9     
- Misses         29       30       +1     
  Partials       24       24              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jameskim0987]

Question for the main contributors -- I observed that there aren't any negative test cases. Would it be worth adding? (ex: https://github.com/crowdin/crowdin-api-client-go/pull/65/files#diff-6aff06001ee42c02818cd8fd62715899b7c539d3bf582ee9a750e93147317d56R110 )

[andrii-bodnar]

@jameskim0987 thank you!

[andrii-bodnar]

@vorobeyme what do you think about negative test cases?

[vorobeyme]

This test function TestReportGenerateRequestValidate and some others are table-driven tests that check the behaviour of the Validate method on different instances of the ReportGenerateRequest structure.

There are already some negative test cases. These are cases where valid is set to false and an error message is expected. See the first few cases in the test table (lines 52-71).

@jameskim0987 if you have another type of negative test case in mind, could you please provide more details?

[jameskim0987]

@vorobeyme I think checking if the required fields are missing is fine. I was thinking more in terms of input validation. For example,

// Split into categories by edit distance.
PostEditingCategories []string `json:"postEditingCategories,omitempty"`

From the API docs example, it looks like for PostEditingCategories it has the value [ "0-10" ] which led me think if we should validate the string format ( I'm not exactly sure what "0-10" signifies nor the entire acceptable format though ).

[vorobeyme]

@jameskim0987

The docs say this field postEditingCategories is just an array of strings (without details), so there is no need to validate its values additionally.

As for the tests, of course, the more possible cases covered, the better. Feel free to proceed.

[jameskim0987]

@vorobeyme Thanks for your input. I will remove the TODO comment since I think we are set then.
@andrii-bodnar let me know if this PR is in good shape

[andrii-bodnar]

@jameskim0987 thanks a lot for your contributions! 🚀