List Comprehensions

Setting module attributes in test files

Now that our first test uses a fixture, we’ll add tests focusing on specific values in the weather API response. Since the module under test (SoggyWaffle.WeatherAPI.ResponseParser) is focused on translating data specific to an external API into internal data, the module must have a lot of knowledge specific to that API. This shows up in the form of all the various weather condition IDs at the top of the module.

Our tests will have to have that same level of knowledge so that they can test the code thoroughly. This means adding a copy of all of the IDs to our test file.

Note: It may seem like a good idea to put them somewhere where both the test and the code under test can access them, but that’s discouraged. Any accidental modifications to that list could cause our test to miss a needed case, allowing our code under test to make it to production with a bug. It would be best to avoid using the Don’t Repeat Yourself (DRY) principle when the instances are split between our tests and our code under test.

In our case, we know that more than one test will likely use those lists of IDs, so we’ll add them as module attributes to the top of the test file.