Fork me on GitHub
#mount
<
2016-08-01
>
jarppe15:08:59

Should mount/stop restore previous states that were overridden using mount/start-with?

jarppe15:08:04

I'm trying to run tests within the same process where I have development REPL

tolitius15:08:14

@jarppe: right mount/stop would "restore" previous states overridden with mount/start-with or swap. are you running tests after you did mount/stop, so any of the dev states would not interfere?

tolitius15:08:13

you can also start a standalone repl just for tests that would watch for changes and rerun. this would be a lot cleaner than running tests within the same repl as you develop. depending on your build tool you can use either: https://github.com/jakemcc/lein-test-refresh or https://github.com/adzerk-oss/boot-test (i.e. boot watch speak test)

jarppe15:08:55

@tolitius: I have app started with (mount/start), the in my tests I try to override DB with (mount/start-with {#'..../db test-db}) and after the tests are done I call (mount/stop). How ever, after the (mount/stop) it seems that all states are in mount.core.NotStartedState state.

jarppe16:08:52

I agree that in general running tests in separate process is better most of the time

tolitius16:08:54

ah.. yes, (mount/stop) would stop all the states, and then would bind them to a NotStartedState

tolitius16:08:42

so the state definitions would still be restored: i.e. your db state's start and stop functions will revert back from the test ones

tolitius16:08:00

but the states values will be NotStartedState after (mount/stop)

jarppe16:08:55

Right, that clears what's going on. Is there some way to restore the previous state values?

tolitius16:08:05

hm.. there should not have been any values previously, since you would need to run (mount/stop) before running the tests not to clash the test states run with the dev values

tolitius16:08:27

i.e. if you have a started db conn in dev, it would need to be stopped before running a test with it

jarppe16:08:19

Yes, that works. Stop everything before tests and start after tests.

jarppe16:08:08

It's just a bit difficult to figure out where this start/stop should happen so that I could run tests both in dev repl, and stand alone "lein test".

tolitius16:08:25

does it take time (to restart after tests), or there are other reasons you would not want to restart?

tolitius16:08:25

if you run your tests in a standalone repl, unless your tests use the same connections (i.e. same db url user/pass), you don't have to stop anything in your dev repl

jarppe16:08:23

No, stop & start is fast, it's just to figure out where to do stop and start. If I put them into clojure.test/use-fixtures the get executed in standalone test runs as well.

jarppe16:08:08

I think I'll just run tests on separate process, that's easier.

tolitius16:08:00

🙂 and cleaner. but just to recap: you can call (mount/stop) before running any tests and you should be good. so whether it is in fixtures or in repl, both should work. (mount/stop) calls take no time if there is nothing to stop, so you can include them before each test if that helps your workflow.

jarppe16:08:44

Right, thanks for your help.

tolitius16:08:36

and if you run it in a separate repl, I would recommend lein-test-refresh or boot watch speak test: let it work for you rather than manually rerun them every time