Weather alert with container

[woodie]

The specs on the mock data were not doing what we'd expect, so I use the fixture data and make clear when we're testing a real payload. It's much easier to work with JSON as a separate file. I format the JSON with jq for readability.

It may be better to have Alert.WeatherAlert instead of WeatherAlert.Summary given that Summary is not the best way to describe everything.

In this PR we also stifle errors from a bad PKEY and allow the specs to run without a .env file.

[jameswpierce]

This LGTM. Approved with the caveat (that you are aware of) that that private key needs to be removed and decommissioned. Thanks for getting this in there, support for this was spotty when the API first came out.

[woodie]

This LGTM. Approved with the caveat (that you are aware of) that that private key needs to be removed and decommissioned. Thanks for getting this in there, support for this was spotty when the API first came out.

OK, the PR is ready. Just for clarification, the PKEY I used was already decommissioned. I assume it must be a properly generated PKEY, but there is no need for it to be active.

We now simply allow(client).to receive(:token) to avoid this issue, but it will be a landmine that future developers could step on. I've also added a fallback so the specs can run without .env or anything in the ENV. With WebMock in place, it's not clear (to me) why we'd even want to load real credentials. @jameswpierce @seeReadCode

[seeReadCode]

Thanks, I'll give it a spin in the next day or two so we can get this merged and released

[drvn-mr]

We now simply allow(client).to receive(:token) to avoid this issue, but it will be a landmine that future developers could step on.

This sounds like the sane thing to do here. Mocking isn't really a problem.
Tests shouldn't be sending outgoing requests or contain sensitive info.