Fork me on GitHub
#component
<
2016-05-26
>
donaldball01:05:41

How do folk approach writing tests for fns that require entire whole systems or components that require more dependencies than is easy to do manually?

donaldball01:05:48

I feel like I keep writing stuff of the form:

donaldball01:05:18

(deftest test-foo
      (let [system (component/start-system (build-test-system (build-test-config)))]
       (try
         …
       (finally (component/stop-system system))))

donaldball01:05:51

with varying amounts of decoration applied to the config or the system in the setup phase

donaldball01:05:18

I’m nearly ready to reach for a macro, but it occurs to me to question my design approach first

sveri06:05:22

@donaldball: for my integration tests I have setup a test system that I start and stop before / after each test with (use-fixtures :each.... Also, my system has a config component that is adapted to the test system. If you have different configs for different tests, either put them in different namespaces, or make the function calling the system take a config parameter.

stuartsierra12:05:12

@donaldball: that's a pretty common approach. You can assoc/dissoc parts of the system before component/start to add/remove specific components for a test. See also https://stuartsierra.com/2016/05/19/fixtures-as-caches for suggestions on reducing the overhead of setup/teardown for tests.