133 lines
5.4 KiB
Gherkin
Raw Normal View History

@example @general
2024-05-26 15:58:33 +01:00
Feature: API Validation
2024-05-27 16:31:00 +01:00
@positive @password
Improve Type Safety and OpenAPI Schema for PDF API Controllers and Models (#3470) # Description of Changes - **What was changed** - Updated controller methods to use strongly‐typed primitives (`int`, `long`, `boolean`) instead of `String` for numeric and boolean parameters, eliminating calls to `Integer.parseInt`/`Long.parseLong` and improving null‐safety (`Boolean.TRUE.equals(...)`). - Enhanced all API request model classes with richer Swagger/OpenAPI annotations: added `requiredMode`, `defaultValue`, `allowableValues`, `format`, `pattern`, and tightened schema descriptions for all fields. - Refactored HTML form templates for “Remove Blank Pages” to include `min`, `max`, and `step` attributes on numeric inputs, matching the updated validation rules. - **Why the change was made** - **Type safety & robustness**: Shifting from `String` to native types prevents runtime parsing errors, simplifies controller logic, and makes default values explicit. - **Better API documentation & validation**: Enriching the Swagger annotations ensures generated docs accurately reflect required fields, default values, and permitted ranges, which improves client code generation and developer experience. - **Consistency across codebase**: Aligning all request models and controllers enforces a uniform coding style and reduces bugs. #3406 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-16 13:23:01 +02:00
Scenario: Remove password
2024-05-26 15:58:33 +01:00
Given I generate a PDF file as "fileInput"
And the pdf contains 3 pages
And the pdf is encrypted with password "password123"
And the request data includes
| parameter | value |
| password | password123 |
When I send the API request to the endpoint "/api/v1/security/remove-password"
Then the response content type should be "application/pdf"
And the response file should have size greater than 0
And the response PDF is not passworded
And the response status code should be 200
2024-05-27 16:31:00 +01:00
@negative @password
2024-05-26 15:58:33 +01:00
Scenario: Remove password wrong password
Given I generate a PDF file as "fileInput"
And the pdf contains 3 pages
And the pdf is encrypted with password "password123"
And the request data includes
| parameter | value |
| password | wrongPassword |
When I send the API request to the endpoint "/api/v1/security/remove-password"
Then the response status code should be 500
And the response should contain error message "Internal Server Error"
2024-05-27 16:31:00 +01:00
@positive @info
2024-05-26 15:58:33 +01:00
Scenario: Get info
Given I generate a PDF file as "fileInput"
When I send the API request to the endpoint "/api/v1/security/get-info-on-pdf"
Then the response content type should be "application/json"
And the response file should have size greater than 100
And the response status code should be 200
2024-05-27 16:31:00 +01:00
@positive @password
2024-05-26 15:58:33 +01:00
Scenario: Add password
Given I generate a PDF file as "fileInput"
And the pdf contains 3 pages
And the request data includes
| parameter | value |
| password | password123 |
When I send the API request to the endpoint "/api/v1/security/add-password"
Then the response content type should be "application/pdf"
And the response file should have size greater than 100
And the response PDF is passworded
And the response status code should be 200
Improve Type Safety and OpenAPI Schema for PDF API Controllers and Models (#3470) # Description of Changes - **What was changed** - Updated controller methods to use strongly‐typed primitives (`int`, `long`, `boolean`) instead of `String` for numeric and boolean parameters, eliminating calls to `Integer.parseInt`/`Long.parseLong` and improving null‐safety (`Boolean.TRUE.equals(...)`). - Enhanced all API request model classes with richer Swagger/OpenAPI annotations: added `requiredMode`, `defaultValue`, `allowableValues`, `format`, `pattern`, and tightened schema descriptions for all fields. - Refactored HTML form templates for “Remove Blank Pages” to include `min`, `max`, and `step` attributes on numeric inputs, matching the updated validation rules. - **Why the change was made** - **Type safety & robustness**: Shifting from `String` to native types prevents runtime parsing errors, simplifies controller logic, and makes default values explicit. - **Better API documentation & validation**: Enriching the Swagger annotations ensures generated docs accurately reflect required fields, default values, and permitted ranges, which improves client code generation and developer experience. - **Consistency across codebase**: Aligning all request models and controllers enforces a uniform coding style and reduces bugs. #3406 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-16 13:23:01 +02:00
2024-05-27 16:31:00 +01:00
@positive @password
Improve Type Safety and OpenAPI Schema for PDF API Controllers and Models (#3470) # Description of Changes - **What was changed** - Updated controller methods to use strongly‐typed primitives (`int`, `long`, `boolean`) instead of `String` for numeric and boolean parameters, eliminating calls to `Integer.parseInt`/`Long.parseLong` and improving null‐safety (`Boolean.TRUE.equals(...)`). - Enhanced all API request model classes with richer Swagger/OpenAPI annotations: added `requiredMode`, `defaultValue`, `allowableValues`, `format`, `pattern`, and tightened schema descriptions for all fields. - Refactored HTML form templates for “Remove Blank Pages” to include `min`, `max`, and `step` attributes on numeric inputs, matching the updated validation rules. - **Why the change was made** - **Type safety & robustness**: Shifting from `String` to native types prevents runtime parsing errors, simplifies controller logic, and makes default values explicit. - **Better API documentation & validation**: Enriching the Swagger annotations ensures generated docs accurately reflect required fields, default values, and permitted ranges, which improves client code generation and developer experience. - **Consistency across codebase**: Aligning all request models and controllers enforces a uniform coding style and reduces bugs. #3406 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-16 13:23:01 +02:00
Scenario: Add password with other params
2024-05-26 15:58:33 +01:00
Given I generate a PDF file as "fileInput"
And the pdf contains 3 pages
And the request data includes
| parameter | value |
| ownerPassword | ownerPass |
| password | password123 |
| keyLength | 256 |
| canPrint | true |
| canModify | false |
When I send the API request to the endpoint "/api/v1/security/add-password"
Then the response content type should be "application/pdf"
And the response file should have size greater than 100
And the response PDF is passworded
And the response status code should be 200
Improve Type Safety and OpenAPI Schema for PDF API Controllers and Models (#3470) # Description of Changes - **What was changed** - Updated controller methods to use strongly‐typed primitives (`int`, `long`, `boolean`) instead of `String` for numeric and boolean parameters, eliminating calls to `Integer.parseInt`/`Long.parseLong` and improving null‐safety (`Boolean.TRUE.equals(...)`). - Enhanced all API request model classes with richer Swagger/OpenAPI annotations: added `requiredMode`, `defaultValue`, `allowableValues`, `format`, `pattern`, and tightened schema descriptions for all fields. - Refactored HTML form templates for “Remove Blank Pages” to include `min`, `max`, and `step` attributes on numeric inputs, matching the updated validation rules. - **Why the change was made** - **Type safety & robustness**: Shifting from `String` to native types prevents runtime parsing errors, simplifies controller logic, and makes default values explicit. - **Better API documentation & validation**: Enriching the Swagger annotations ensures generated docs accurately reflect required fields, default values, and permitted ranges, which improves client code generation and developer experience. - **Consistency across codebase**: Aligning all request models and controllers enforces a uniform coding style and reduces bugs. #3406 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-16 13:23:01 +02:00
2024-05-27 16:31:00 +01:00
@positive @watermark
2024-05-26 15:58:33 +01:00
Scenario: Add watermark
Given I generate a PDF file as "fileInput"
And the pdf contains 3 pages
And the request data includes
| parameter | value |
| watermarkType | text |
| watermarkText | Sample Watermark |
| fontSize | 30 |
| rotation | 45 |
| opacity | 0.5 |
| widthSpacer | 50 |
| heightSpacer | 50 |
Improve Type Safety and OpenAPI Schema for PDF API Controllers and Models (#3470) # Description of Changes - **What was changed** - Updated controller methods to use strongly‐typed primitives (`int`, `long`, `boolean`) instead of `String` for numeric and boolean parameters, eliminating calls to `Integer.parseInt`/`Long.parseLong` and improving null‐safety (`Boolean.TRUE.equals(...)`). - Enhanced all API request model classes with richer Swagger/OpenAPI annotations: added `requiredMode`, `defaultValue`, `allowableValues`, `format`, `pattern`, and tightened schema descriptions for all fields. - Refactored HTML form templates for “Remove Blank Pages” to include `min`, `max`, and `step` attributes on numeric inputs, matching the updated validation rules. - **Why the change was made** - **Type safety & robustness**: Shifting from `String` to native types prevents runtime parsing errors, simplifies controller logic, and makes default values explicit. - **Better API documentation & validation**: Enriching the Swagger annotations ensures generated docs accurately reflect required fields, default values, and permitted ranges, which improves client code generation and developer experience. - **Consistency across codebase**: Aligning all request models and controllers enforces a uniform coding style and reduces bugs. #3406 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-16 13:23:01 +02:00
| alphabet | roman |
| customColor | #d3d3d3 |
2024-05-26 15:58:33 +01:00
When I send the API request to the endpoint "/api/v1/security/add-watermark"
Then the response content type should be "application/pdf"
And the response file should have size greater than 100
And the response status code should be 200
2024-05-27 16:31:00 +01:00
@positive
2024-05-26 15:58:33 +01:00
Scenario: Remove blank pages
Given I generate a PDF file as "fileInput"
And the pdf contains 3 blank pages
And the request data includes
| parameter | value |
| threshold | 90 |
| whitePercent | 99.9 |
When I send the API request to the endpoint "/api/v1/misc/remove-blanks"
2024-08-03 10:44:17 +01:00
Then the response content type should be "application/octet-stream"
And the response file should have extension ".zip"
2024-08-03 13:47:47 +01:00
And the response ZIP should contain 1 files
2024-05-26 15:58:33 +01:00
And the response file should have size greater than 0
2024-05-27 16:31:00 +01:00
@positive @flatten
2024-05-26 15:58:33 +01:00
Scenario: Flatten PDF
Given I generate a PDF file as "fileInput"
And the request data includes
| parameter | value |
| flattenOnlyForms | false |
When I send the API request to the endpoint "/api/v1/misc/flatten"
Then the response content type should be "application/pdf"
And the response file should have size greater than 0
And the response status code should be 200
Improve Type Safety and OpenAPI Schema for PDF API Controllers and Models (#3470) # Description of Changes - **What was changed** - Updated controller methods to use strongly‐typed primitives (`int`, `long`, `boolean`) instead of `String` for numeric and boolean parameters, eliminating calls to `Integer.parseInt`/`Long.parseLong` and improving null‐safety (`Boolean.TRUE.equals(...)`). - Enhanced all API request model classes with richer Swagger/OpenAPI annotations: added `requiredMode`, `defaultValue`, `allowableValues`, `format`, `pattern`, and tightened schema descriptions for all fields. - Refactored HTML form templates for “Remove Blank Pages” to include `min`, `max`, and `step` attributes on numeric inputs, matching the updated validation rules. - **Why the change was made** - **Type safety & robustness**: Shifting from `String` to native types prevents runtime parsing errors, simplifies controller logic, and makes default values explicit. - **Better API documentation & validation**: Enriching the Swagger annotations ensures generated docs accurately reflect required fields, default values, and permitted ranges, which improves client code generation and developer experience. - **Consistency across codebase**: Aligning all request models and controllers enforces a uniform coding style and reduces bugs. #3406 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-16 13:23:01 +02:00
2024-05-27 16:31:00 +01:00
@positive @metadata
2024-05-26 15:58:33 +01:00
Scenario: Update metadata
Given I generate a PDF file as "fileInput"
And the request data includes
| parameter | value |
| author | John Doe |
| title | Sample Title |
| subject | Sample Subject |
| keywords | sample, test |
| producer | Test Producer |
When I send the API request to the endpoint "/api/v1/misc/update-metadata"
Then the response content type should be "application/pdf"
And the response file should have size greater than 0
And the response PDF metadata should include "Author" as "John Doe"
And the response PDF metadata should include "Keywords" as "sample, test"
And the response PDF metadata should include "Subject" as "Sample Subject"
And the response PDF metadata should include "Title" as "Sample Title"
And the response status code should be 200
Improve Type Safety and OpenAPI Schema for PDF API Controllers and Models (#3470) # Description of Changes - **What was changed** - Updated controller methods to use strongly‐typed primitives (`int`, `long`, `boolean`) instead of `String` for numeric and boolean parameters, eliminating calls to `Integer.parseInt`/`Long.parseLong` and improving null‐safety (`Boolean.TRUE.equals(...)`). - Enhanced all API request model classes with richer Swagger/OpenAPI annotations: added `requiredMode`, `defaultValue`, `allowableValues`, `format`, `pattern`, and tightened schema descriptions for all fields. - Refactored HTML form templates for “Remove Blank Pages” to include `min`, `max`, and `step` attributes on numeric inputs, matching the updated validation rules. - **Why the change was made** - **Type safety & robustness**: Shifting from `String` to native types prevents runtime parsing errors, simplifies controller logic, and makes default values explicit. - **Better API documentation & validation**: Enriching the Swagger annotations ensures generated docs accurately reflect required fields, default values, and permitted ranges, which improves client code generation and developer experience. - **Consistency across codebase**: Aligning all request models and controllers enforces a uniform coding style and reduces bugs. #3406 --- ## Checklist ### General - [x] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [x] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md) (if applicable) - [x] I have performed a self-review of my own code - [x] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#6-testing) for more details.
2025-05-16 13:23:01 +02:00