Fork me on GitHub
Andrew Lai18:02:51

Hi testing channel! I’m looking for some input and advice regarding testing functions that accept configuration values. The concrete example I’m working on is a program where I route SQS messages to different handlers. When I receive a message, the router tries to match the given file path against the route table to see if there are any matches, and dispatches the first matching handler. In this program I separated the function that does routing (the router) from a regular-expression based route table (e.g. {#"some-path/\.csv" some-handler})such that the route table is an input to the router ; the signature is (defn router [route-table message]). I’m looking for some advice regarding structuring tests. I can test the route table in isolation by passing in route tables that I wouldn’t necessarily use in production (e.g. {#".*" always-throw-handler} ). This has been very valuable for writing small, focused tests. But this kind of test doesn’t actually test the program as it would be configured in production. It seems like there are two questions I want my tests to answer - “does the router work?” and second “is the route-table configured properly to produce the behavior I care about in prod?” How have you approached testing both how a function works and how it is configured? Specifically looking for advice regarding code organization and if you use different approaches (e.g. mix behavioral tests and unit tests?)