Create and teardown S3 state, instead of relying on it being there

[jarednielsen]

That way our test suite is standalone, without undocumented state.

s3://smdebug-testing/resources/event-files-missing
s3://smdebug-testing/resources/has_step_scenarios
s3://smdebug-testing/resources/one-index-files
s3://smdebug-testing/resources/dist-logs-10

[Vikas-kum]

I dont think we should teardown. Data shouldn't change helps me in trusting that there was no regression.

[jarednielsen]

Agreed that the data shouldn't change. The data should come from the test though, that's the point of a "unit" test.

[Vikas-kum]

Agreed that the data shouldn't change. The data should come from the test though, that's the point of a "unit" test.

If we are creating and deleting data in s3, then there is chance that we would mess with the data.
This is not unit test. If we want unit test, we should mock s3 client and not hit s3.
Hope this makes it clear.
Also, if this is part of s3, then people who dont have s3 won't be able run the unit test. May be we should move all test which hits s3 as part of CI only rather than unit test(use skipif test annotation for test which are trying to access s3). This way the tests will not fail and people doesn't need to have s3 account or access.
If CI s3 test breaks on existing data, then we want some eyes on it, rather than making it easy to modify the s3 data.