@onetom: that's true. in case try/catch is not something you like, what do you prefer instead?

and yes, for web server and such, you can control the :reload behavior: https://github.com/tolitius/mount/blob/master/README.md#on-reload

@tolitius: i just think the try/finally is a detail which should be hidden in around hooks (or fixtures in clojure.test terminology) but omitting try/finally leads to cascading errors and confusing error messages.

there must be some fundamental difference in how we think about testing probably... i feel like im doing something wrong, because i have some implicit expectations which others don't have

btw, i re-read your disturbance-in-the-force article about the implicit vs explicit formalism last night. probably that mind-set difference makes it hard to convey my problem.

i very much share your observations > The “Clojure Gods” talk a lot about state, but very rarely about an application state and codebase organization. I doubt Datomic uses Component, but I don’t know.

@onetom: the port that you're running test web server on might be in use by yet another app. I usually initialize things that require ports in a loop until it can find a working one. Obviously if a server never gets stopped it would leak. In this case I found it best to rely on test fixtures in whatever form the test framework supports them.

@onetom: 1. Might make sense to isolate tests in a way that they do not span many components. I usually start one of two components in a single test (mount/start a b) or (-> (only a b) ... (mount/start)). in which case it is easier to have a finer control in fixtures. 2. I tend to write my tests in a way that they are quick to run: i.e. so something changes I can tolerate rerunning most if not all of them 3. For tests that span the whole, or almost the whole app (most of the components), I either keep them in test sources when rerunning all, in case they are quick to run, or I would not include them in the general test sources, but would in others which gives me a way to either run them separately or to run them as a part of committing things: or / i.e. before pushing 4. Also (this will not help, but rather a philosophical point) working for several years in Clojure I notice that I do not stress about my test coverage as I once did, and mostly only test "the important" things: something that will help in regression. Since most of the things I test rigorously in the REPL. I believe this might be a reason I have not experienced many problems that I read about (i.e. problems of testing frameworks, "revolutionary ideas" in test industry..). It might have to do with an ability of keeping the whole app in my head when I develop (it is not always possible depending on the project), but I find that I spend lots of time in REPL, hence I do not find myself in a situation where I need to cmd-shift-a "run tests in current NS in REPL", but I do understand and respect that development flow of others can be, and is, different.