doc: how to prevent Midje to be compiled in production code?

[denlab]

Yes there's: https://github.com/marick/Midje/wiki/Production-mode

But there is not all the informations that we need to deactivate Midje:

To prevent Midje facts and expects from being compiled into your code, set midje.semi-sweet/include-midje-checks to false. Midje also obeys clojure.test's load-tests.

Can you elaborate on the strategy to put in place to avoid compile the Midje tests: Where should we set this variable? Because setting it in a top level namespace won't work as it will be loaded at the end and then the tests will be deactivated only for this ns.

Maybe give a link to a project that already do that, so we can take it as an example.

PS: I find having the tests and the prod code in the same file awesome, especially when coupling it with literate programming (marginalia), because then, when you read the literal doc you have a crystal clear description of the code :

• human explanation nicely formatted
• and "real" specifications: the executable tests.

But we recently tried to deploy a Clojure app on Heroku, and we needed to separate prod code from tests in different directories.

[marick]

I'm going to put this off until 1.5 because this should be part of project / user configuration, probably implemented via Leiningen 2.

[giorgio-v]

I didn’t even know you can include tests in function defintions. Does it work in the same way as clojure.test (example from Joy of Clojure)?

(defn join
  {:test (fn []
           (assert
             (= (join "," [1 2 3]) "1,3,3")))}
  [sep s]
  (apply str (interpose sep s)))

[marick]

clojure.test is driven off var metadata. If you say deftest foo ..., then the body of the deftest gets added to the :test metadata of #'foo. Clojure.test's run-tests looks at all the vars in a namespace. If it finds :test metadata, it runs those tests. That allows you to add tests to a function definition.

That's a very different model from Midje:

• In the earlier Midje, facts were checked as they were loaded, then immediately discarded.
• In 1.5, loaded facts are stored in the compendium. They're not attached to a particular var.

1.5 adds "names" for facts. If you're testing vary-meta, you could write this:

(fact vary-meta ...)

It would not be hard to add the fact as metadata on #'vary-meta, but I'd want to see some evidence that people actually want to independently run tests for a particular var, vs. for a whole namespace or for one of Midje's search criteria.

[giorgio-v]

Il giorno 22/feb/2013, alle ore 01:35, Brian Marick ha scritto:

clojure.test is driven off var metadata. If you say deftest foo ..., then the body of the deftest gets added to the :test metadata of #'foo. Clojure.test's run-tests looks at all the vars in a namespace. If it finds :test metadata, it runs those tests. That allows you to add tests to a function definition.

That's a very different model from Midje:

In the earlier Midje, facts were checked as they were loaded, then immediately discarded.

In 1.5, loaded facts are stored in the compendium. They're not attached to a particular var.

1.5 adds "names" for facts. If you're testing vary-meta, you could write this:

(fact vary-meta ...) It would not be hard to add the fact as metadata on #'vary-meta, but I'd want to see some evidence that people actually want to independently run tests for a particular var, vs. for a whole namespace or for one of Midje's search criteria.

I see. So, right now (or rather, when Midje 1.5 wile be released) it’s not possible to embed tests. Correct?

[marick]

You could embed them in the same way that the join example shows, but there's nothing in the Midje code that can extract those tests and run them.

[jjl]

It's possible to strip midje out the hard way. I'm using this at present while I'm waiting for a better way https://gist.github.com/jjl/266e4fd88846ab8674f4

[marick]

Just as a note: I now use the conventional separation of test code and, uh, code code into test and src directories. With fixed-purpose split windows, I actually find that does a better job of keeping the test code and source code simultaneously visible.