Create Unit Tests for each Symbol & Feed Handle Point

[jnmclarty]

Symbol

• caching
• concatenation (of feeds)
• aggregation (of final value column)
• validity_check

Feed

• api_failure
• empty_feed
• index_type_problem
• index_property_problem
• data_type_problem
• monounique

[jnmclarty]

@Asiant (or anybody interested in tackling this issue)

Trump's caching process takes responses from a range of sources for data. Handling all the edge cases, would be too extensive from Trump to do, so instead, if there's a problem at certain points in the process, the handle point decides what to do with certain kinds of problems - depending on settings in the Symbol/Feed's Handle settings ( RAISE / WARN / LOG / E-MAIL / etc.)

So, for instance, let's assume we have symbol with just one feed. The feed is set up, to source data from a database table somewhere. But, through something unrelated to Trump, the table is dropped, or even renamed. When Trump tries to cache the data, there would be an api_failure.

Now, admittedly, it wouldn't make sense to only warn, on an api_failure, for a symbol with only one feed - because everything downstream would fail. (Eg. it couldn't handle index-type conversion) But, if there were two or more, maybe if one feed is down, it's okay to proceed, because the back-up feed will work.

To create tests for each, one will have to make error cases.

The EASIEST one to start on would be the api_failure. You could duplicate (copy/paste) one of the tests which relies on a CSV source file (ctrl-f "csv" in test_orm.py ), and make a copy of the CSV data file that the test uses. Change the contents of the new CSV file, so that it fails to get data from it. Maybe delete the column of data it's looking for, for instance. As soon as trump tries to fetch it, you'll have the api_failure case done. One would need to catch the exception, and check the message somehow, to make sure that the test properly tests the failure (and not some other failure).

[jnmclarty]

#61