Clojurians Log v2

Is it possible attach a fixture only to a few tests within a namespace?

@boccato Not directly, but you could add metadata on those tests and check for the metadata in the fixture. I think. Not sure if the fixture is passed the Var or just the function value.

Hmm, nope. The fixture is passed the test function, not the Var. That's a shame.

Not sure what to suggest. I guess I'd probably break those tests out into a separate namespace and add the special fixture to that new namespace...

@boccato I’m not sure if it helps but in our projects we defined a macro to clean up the test’s fixture from our DB. Maybe you could use the macro when you need some additional stuff done for the test.

(defonce ^:dynamic *db*
  (-> (db-config-for :test)
      new-db
      component/start
      (assoc :enable? false)))

(defn clean
  [f]
  (jdbc/with-db-transaction [db *db*]
    (jdbc/db-set-rollback-only! db)
    (binding  [*db* db]
      (try
        (f)
        (catch SQLException e
          (prn (.getNextException e))
          (throw e))))))

(defmacro def-integration-test
  [test-name & body]
  `(deftest ~(vary-meta test-name assoc :integration true)
     (clean (fn [] ~@body))))

I m leaning towards separating them in namespaces. Thanks for the reply.

This is just an example. We use the dynamic *db* in our tests to make it easier to CRUD the db without worrying about cleaning up the DB in the context of the test. The :integration keyword is useful to filter the tests and run them in parallel in our pipeline.

Definetly helps to see how ppl tackle similar problems... liked the idea of creating a diferent kind of deftest but in my case might be overkill.

So in the same namespace, you might find deftest for pure fns and def-integration-test for fns with side effects. For us, it’s very easy to spot the difference.

Yeah... I liked the approach.

Will keep your code, it might be handy in the future.

Of course, we reached that code after trying simpler options. It’s only useful when you have the need.