This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-02
Channels
- # announcements (4)
- # aws (18)
- # beginners (227)
- # boot (1)
- # calva (13)
- # cider (22)
- # clara (2)
- # cljs-dev (17)
- # clojure (85)
- # clojure-brasil (2)
- # clojure-dev (55)
- # clojure-europe (2)
- # clojure-italy (18)
- # clojure-japan (4)
- # clojure-losangeles (1)
- # clojure-nl (5)
- # clojure-uk (53)
- # clojurescript (46)
- # clojureverse-ops (8)
- # cursive (17)
- # data-science (3)
- # datascript (3)
- # datomic (25)
- # duct (4)
- # emacs (2)
- # figwheel-main (1)
- # fulcro (9)
- # hoplon (2)
- # hyperfiddle (1)
- # jobs-discuss (5)
- # kaocha (7)
- # leiningen (3)
- # nrepl (50)
- # off-topic (32)
- # portland-or (1)
- # re-frame (19)
- # reitit (2)
- # shadow-cljs (30)
- # spacemacs (2)
- # sql (8)
- # tools-deps (4)
- # vim (26)
- # xtdb (3)
- # yada (8)
This may be a dumb question, but how are people deciding to split and name their different testing levels? e.g., have a test/unit
and test/integration
; but if I say unit test foo.bar
, I’m going to have test/unit/foo/bar_test.clj
, with test-ns foo.bar-test
. If I also want to have integration tests, I’m going to have test/integration/foo/bar_test.clj
, with test-ns foo.bar-test
. I now have two identical namespaces. I want to keep the parity between the src and test namespaces, so stuff like “jump to test file” works. So how is everyone else doing it?
Although I guess after reading it, “jump to test file” wouldn’t work anymore regardless, so that’s a non-issue.
Are people essentially just prefixing the unit.
and integration.
onto their namespaces?
For a concrete example; unit testing vs real-http-request testing a ring handler and cleanly separating the two
We're actually grappling with something similar at work, but at a more fundamental level "what is a unit test?", "when is a test considered integration?" etc. At a glance, it seems like pre/postfixing, that's what I'm currently doing with generative tests.
@U0E2EQFME my integration tests generally are organized by the features they test, rather than the namespaces under test. Since they integrate multiple pieces there is no one-to-one mapping between test and namespace there.
I 100% agree with @U07FP7QJ0 — In my experience you’re much, much better organising applications by vertical features at the top rather than by horizontal concerns.
Within a feature you can then split horizontally if you need to.
i.e. app.tweet
app.profile
app.direct-message
app.search
rather than app.handler
app.middleware
app.models
…
Tests then follow a similar structure - though you may have something like app.search.integration