component

donaldball 2016-05-26T01:02:41.000067Z

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?

donaldball 2016-05-26T01:02:48.000068Z

I feel like I keep writing stuff of the form:

donaldball 2016-05-26T01:04:18.000069Z

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

donaldball 2016-05-26T01:04:51.000070Z

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

donaldball 2016-05-26T01:05:18.000071Z

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

sveri 2016-05-26T06:14:22.000072Z

@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.

stuartsierra 2016-05-26T12:38:12.000073Z

@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.