Answering in two parts: 1. The most direct way I can think of to see if a server exists is to try and open up a socket to that port. 2. While it's an interesting exercise, I suspect your time will be better spent testing things farther up the stack. This is essentially testing the web server itself, which has probably already received a lot of attention by many people.

You’re definitely right that testing to make sure a server exists is pretty trivial.

Now a follow up question. How should I configure my test suite to make sure my server is running on each test run. I’m probably gonna use httpkit, so would I just call run-server from my test file?

If you really want end-to-end tests, then yes. use-fixtures can help structure this code, if you feel it's repetetive: https://clojuredocs.org/clojure.test/use-fixtures. That said, it's common to structure clojure code such that most of the pieces are purely functional, and can be tested independent of any kind of fixture situation. For example, you'll probably have request handlers that are little more than a function. Most testing can be done on that function directly. Of course the integration tests should still exist, but people usually don't write as many of those.

Well thank you for your help, and thank you for introducing me to use-fixtures! That’s a really big help for me.

For basic smoke test I recommend adding a simple route like /status that would return pkain text “ok” on GET

If you do end up using fixtures, the following link might be helpful. https://stuartsierra.com/2016/05/19/fixtures-as-caches

A deftest inside a testing seems quite weird. It can also complicate a little bit on async tests in ClojureScript, so I would recommend against it

Also, testing updates the :testing-contexts but inside a dynamic var. What it means, in practice, is the following (using your first example):

; Here, it'll update the testing context to ["desc"]
(testing "desc"
  (deftest "case1"
     ; Here, it'll update the testing context to ["desc" "this texts x"]
    (testing "this tests x" 
      ...
    ) ; Here, it'll be back to ["desc"]
  )
) ; And here, to []

As the testing-context is a global, dynamic var, this "binding-rebinding" will work *if* (and that's a big IF) ClojureScript loads the file AND run the tests at the same time. Most of the time, that's not the case, so what it'll happen is something like this:

; Here, it'll update the testing context to ["desc"]
(testing "desc"
  (deftest case1 ; Here, it'll just define the var
    (testing "this tests x" ... )
  )
); Back to []

I think they just wrote that for reading context, and wrapping a let that covers the deftest with shared context

it was agreed to back it out, but it piqued my curiosity enough that I wanted to get a deeper understanding. 😉

Kinda, but the testing description appears when a test fails also

For example:

user=> (deftest sum-numbers (testing "1+2" (testing "must be 3" (is (= 2 (+ 1 2))))))
#'user/sum-numbers
user=> (run-tests)

Testing user

FAIL in (sum-numbers) (NO_SOURCE_FILE:1)
1+2 must be 3
expected: (= 2 (+ 1 2))
  actual: (not (= 2 3))

yeah, again I am not sure if they did that for extra description context, or more the idea of wrapping a let block

I think they did, otherwise I see no value on adding that :testing-contexts element

they were able to run it they said; but the docstring said inside deftest only, so felt like it would be a loophole that might be able to be exploited, but didn’t feel like we should be counting on it…

If you look at git blame, it seems it was intentional

It's inside deftest because otherwise the description will not be added to failures