prowler-test-sdk_skill
- Python
12.8k
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill prowler-cloud/prowler --skill prowler-test-sdk- SKILL.md10.0 KB
Overview
This skill documents testing patterns and conventions for the Prowler SDK (Python) focused on provider-specific unit tests. It explains required test scenarios, mocking approaches per provider, fixtures, file layout, and assertion expectations. The goal is to make tests consistent, reliable, and easy to maintain across AWS, Azure, GCP, Kubernetes, and other providers.
How this skill works
The skill prescribes different mocking strategies per provider: use the moto library with the @mock_aws decorator for AWS, and use unittest.mock.MagicMock for Azure, GCP, Kubernetes and others. It enforces importing checks inside the patch context so the mocked clients are used during check execution. Fixtures provide provider-specific constants and helper functions like set_mocked_{provider}_provider to create a test provider object.
When to use it
- When writing unit tests for Prowler checks, services, or provider clients.
- When creating provider-specific test setups (AWS resources vs. Azure/GCP mocks).
- When validating required test scenarios: compliant, non-compliant, and no-resources.
- When adding new provider support or updating existing check behavior.
Best practices
- Never use moto for non-AWS providers and never use MagicMock for AWS.
- Import the check inside the mock.patch context so the patched client is used.
- Always include the three required scenarios: PASS, FAIL, and no resources.
- Use provider fixtures (set_mocked_{provider}_provider and constants) from tests/providers/{provider}/
- Assert both status and metadata (status_extended, resource_id/name and provider-specific fields)
Example use cases
- Write an AWS S3 bucket check test using @mock_aws and moto to create compliant and non-compliant buckets.
- Test an Azure resource check by injecting a MagicMock service client with subscription-scoped resources.
- Create a GCP check test using set_mocked_gcp_provider and MagicMock to simulate project resources.
- Add Kubernetes service tests using set_mocked_kubernetes_provider and MagicMock for cluster objects.
FAQ
Importing inside the patch context ensures the module binds to the patched client or service object so the check uses the mock during execution.
What assertions are mandatory for every check test?
Always assert status (PASS/FAIL), status_extended with the expected message, resource_id, resource_name and provider-specific fields like region, subscription, or project_id.
