Scalable Test Harness over many DICOMs

[suyashkumar]

We should consider building a more scalable test harness. As the test set of DICOMs grow, we should not be committing these dicom blobs into git. Instead, we should have a set of lightweight sanity checks along with unit tests that run based on information in the repository, and on demand (or before merging into master) we should be able to trigger a test routine where we fetch a (larger) collection of DICOMs from cloud storage and run simple parse-failure checks over all of them.

[wkoszek]

@suyashkumar Do you have any examples for writing new DICOMs with your library?

[suyashkumar]

Nothing yet other than what you can find in the tests here: https://github.com/suyashkumar/dicom/blob/master/write/writer_test.go. Most of the write package code was inherited from upstream fork, and I haven't done much in that area. Would be great to start to improve this portion of the library if you have any requests.

[wkoszek]

@suyashkumar I'll discuss with @IChocked We would benefit from this functionality for CI/CD functionality, where I'd really like to generate some DICOMs created from the code.

[suyashkumar]

Sounds good, one option I've been looking into for "smoke test" level coverage is using GIT LFS with GitHub to store the DICOM binary blobs.

[suyashkumar]

So, I need to look into GIT LFS some more for hosting these test files. It seems like repos that use GIT LFS may not work well with go get w/modules (even if the LFS assets are not needed to build the dependency and are only used for tests). I've only just taken a cursory glance at golang/go#39720. This needs to be investigated further, but in the meantime to unblock e2e tests I will add some smaller sets of test files directly into the git repo to help provide some regression coverage.