This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-16
Channels
- # aws (6)
- # beginners (129)
- # calva (9)
- # cider (4)
- # cljs-dev (2)
- # clojure (41)
- # clojure-beijing (2)
- # clojure-dev (3)
- # clojure-spec (23)
- # clojure-uk (46)
- # clojurescript (38)
- # community-development (20)
- # core-async (4)
- # cursive (12)
- # data-science (7)
- # datascript (13)
- # datomic (15)
- # duct (11)
- # emacs (18)
- # figwheel-main (5)
- # fulcro (26)
- # off-topic (4)
- # pathom (28)
- # pedestal (3)
- # reagent (8)
- # reitit (6)
- # shadow-cljs (32)
- # specter (3)
And maybe an integration testing would be to compose "unit tests". for example - List resources: empty - Create resource: return resource - List resource: list with the created resource - Update the resource: return the updated resource ...and so on. Is this the idea of an integration testing?
I think that’s consistent with integration testing. In my experience, the term integration testing has been used to describe end-to-end tests which exercise the system in the context of backing infrastructure/dependencies (i.e., real database, externally deployed services, etc…)
For the unit test, we could also use let to get the response and use it to multiple "assertions"
(let [response (response-for service
:post "/foo"
:headers {"Content-Type" "application/json"}
:body "{\"foo\":\"bar\"}")]
(is (= 200 (:status response)))
(is (= {"foo": "bar"} (:body response))))