Mock Route53 change_resource_record_sets in Python
This code demonstrates how to mock AWS Route53 change_resource_record_sets API calls using the botocore Stubber, allowing you to test DNS update logic without touching real infrastructure.
pip install boto3
Python code
59 linesimport boto3
from botocore.exceptions import ClientError
def mock_change_resource_record_sets():
"""Demonstrates Route53 change_resource_record_sets with a mock client."""
# Create a mock Route53 client
route53 = boto3.client('route53', region_name='us-east-1',
aws_access_key_id='fake', aws_secret_access_key='fake')
# Mock the change_resource_record_sets response
mock_response = {
'ChangeInfo': {
'Id': '/change/C1234567890123',
'Status': 'PENDING',
'SubmittedAt': '2024-01-15T10:00:00Z',
'Comment': 'Mock change for demonstration'
}
}
# Use botocore stubber to simulate AWS response
from botocore.stub import Stubber
stubber = Stubber(route53)
change_batch = {
'Changes': [
{
'Action': 'UPSERT',
'ResourceRecordSet': {
'Name': 'example.com.',
'Type': 'A',
'TTL': 300,
'ResourceRecords': [{'Value': '192.0.2.1'}]
}
}
]
}
expected_params = {
'HostedZoneId': 'Z1234567890',
'ChangeBatch': change_batch
}
stubber.add_response('change_resource_record_sets', mock_response, expected_params)
stubber.activate()
try:
response = route53.change_resource_record_sets(
HostedZoneId='Z1234567890',
ChangeBatch=change_batch
)
return response['ChangeInfo']
except ClientError as e:
return {'Error': str(e)}
finally:
stubber.deactivate()
if __name__ == "__main__":
result = mock_change_resource_record_sets()
print(result)
Output
{'Id': '/change/C1234567890123', 'Status': 'PENDING', 'SubmittedAt': '2024-01-15T10:00:00Z', 'Comment': 'Mock change for demonstration'}
How it works
The code uses boto3.client to create a Route53 client, then wraps it with a Stubber from botocore. The stubber intercepts the change_resource_record_sets call and returns a pre-defined mock response when the exact expected parameters match. This lets you test your AWS integration logic without hitting the real AWS API. The expected parameters are specified in expected_params and must exactly match what the client sends. The stubber is activated before the call and deactivated in a finally block to ensure cleanup. By mocking the client this way, you can validate your code's logic, error handling, and response parsing reliably in a local development or CI environment.
Common mistakes
- Forgetting to activate the stubber before making the API call
- Not matching the expected parameters exactly, causing a mismatch error
- Leaving the stubber active after the test, which can interfere with other calls
- Assuming the real AWS client is needed instead of a mock for unit tests
Variations
- Use `moto` to mock the entire Route53 service for more complex scenarios
- Use the `unittest.mock` patch to replace the client method directly
Real-world use cases
- Unit testing a script that updates DNS records during deployment to ensure it doesn't break the real zone.
- Validating CI/CD pipeline code that modifies Route53 records before applying it to production.
- Simulating Route53 API responses in a development environment to debug your integration without incurring AWS costs.
Sponsored
More from Cloud + Python
- Build a URL Shortener Client with Python medium
- Create a Cloud Storage Helper Class in Python easy
- Create a Data Helper Class for Beginners in Python easy
- Cross Account Role Chaining Mock Credentials in Python medium
- Exponential Backoff with Jitter for Cloud API Calls in Python medium
- Generate Mock CloudFormation Stack Events in Python easy
Keep learning
Related tutorials and quizzes for this topic.