Clojurians Log v2

it’s common to reach around that by var access. (#'ns-prefix/private-var :foo)

others argue pretty strongly that private functions should not be tested, only the api of the namespace.

ok thanks @dpsutton that’s something to think about

You can rely on a gentlemen's agreement and put all private functions in an impl namespace

To expand on the point raised by dpsutton: If a private function is defined then ideally it would be very generic and used by numerous other public functions (the API of the namespace). Therefore any private functions can be covered via tests on those public functions. Testing private functions can make the test suite more brittle to change, take longer to do a test run and increase the overall maintenance of the test suite.

I don't remember the last time I wrote a private function! When functions "don't belong" in the namespace, I mostly move them to a different namespace.

yeah I worked on this last night and what you all are saying makes sense; however if the test of the api is “expensive” then that’s maybe one reason or pressure to test the private function directly

like

(defn hit-the-database [db] (db-driver (private-fn-generates-table-name-or-whatever) ...))

any pros/cons for putting the tests in the namespace with the code?

con is that it will be in your artifact. The traditional path is in a separate classpath root that you optionally add in and contains essentially a mirror shape of your namespaces with -test added as a suffix