You can use dev instance, and for S3 there is actually a whole fake server :-)
But when you work with external libraries/services – you better work with real thing, because mocking it will hide real problems from you.
And if you have a nice wrapper around S3 lib – you won't have to test error handling every time you have to interact with this service. You'll have a set of tests that check if S3 still has the same interface and interacts with you in expected manner.
I think ideally you would have both. During development, it makes no sense to tie your unit tests to anything outside of the architectural boundaries. Taking it a step further I would actually opposite and say "Mock What you Don't Own".
The integration layer should handle verifying the plumbing of components outside of the architectural boundaries.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You can use dev instance, and for S3 there is actually a whole fake server :-)
But when you work with external libraries/services – you better work with real thing, because mocking it will hide real problems from you.
And if you have a nice wrapper around S3 lib – you won't have to test error handling every time you have to interact with this service. You'll have a set of tests that check if S3 still has the same interface and interacts with you in expected manner.
I think ideally you would have both. During development, it makes no sense to tie your unit tests to anything outside of the architectural boundaries. Taking it a step further I would actually opposite and say "Mock What you Don't Own".
The integration layer should handle verifying the plumbing of components outside of the architectural boundaries.