This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-21
Channels
- # beginners (65)
- # boot (24)
- # cider (2)
- # clara (13)
- # cljs-dev (45)
- # clojure (48)
- # clojure-dusseldorf (2)
- # clojure-italy (69)
- # clojure-norway (1)
- # clojure-russia (5)
- # clojure-sanfrancisco (1)
- # clojure-spec (51)
- # clojure-uk (34)
- # clojurescript (312)
- # cursive (5)
- # datavis (1)
- # datomic (9)
- # duct (13)
- # editors (3)
- # emacs (2)
- # fulcro (11)
- # graphql (19)
- # hoplon (1)
- # immutant (2)
- # jobs (7)
- # jobs-discuss (38)
- # lein-figwheel (1)
- # luminus (6)
- # off-topic (2)
- # parinfer (10)
- # pedestal (1)
- # re-frame (9)
- # reagent (28)
- # reitit (1)
- # remote-jobs (12)
- # ring-swagger (26)
- # shadow-cljs (232)
- # slack-help (8)
- # tools-deps (29)
- # unrepl (29)
- # vim (10)
- # yada (31)
What are the current suggested testing approaches for Reagent SPAs?
My recommendation is to unit test components/event handlers/other functions and at the most have one smoke test to validate that the app loads on browser or something similar.
And to be honest, I don't even test components or event handlers usually, but if I have some logic that I think is worth testing, I move the function to cljc namespace so I can easily test it using Clj test runner.
we do that ^ and have a few tests run on phantomjs too - because e.g. regex behave differently on js than jvm
For some libraries (like Reagent, reitit), I run tests on Node/Chrome headless with Doo also, but usually I haven't found that necessary with applications
I have an older project that ran tests in figwheel, and I really liked it. I assume I can still do that, but I don’t see docs for it on the official site.
@bhauman wrote code that would turn your browser tab favicon green or red based on the results of the test run, and it was great.
For reusable component library type projects, Figwheel + Devcards is nice
That’s a good idea, though, moving code to cljc and testing there.
testing is tricky
I think the most useful thing is the smoke test @juhoteperi mentioned
unfortunately it's also hard to build from an ops perspective
you need a db with mock data, a server running, you need to start and stop everything, and then there's the brittleness of selenium tests
lots of JS programmer test way too much IMO
unit-testing UI (or any non-algorithmic) code doesn't seem all that useful to me
I'd love to hear stories from people who have a setup they like (even in non-cljs environments)
I worked with setting up the test environment for the Norwegian BankID Client 2.0 which was a pure HTML/CSS/JS implementation where they had to test over 50 different combinations of hardware and browsers. Very brittle, lots of work when tests need to be rewritten, prone to breaking. There is value in it, and for something high profile like a BankID client I would argue there is a lot of value. It's incredibly expensive to set up and has a high upkeep cost
Is there any documentation on using React components written in JavaScript?
@alex-dixon Yeah, @lee.justin.m put together a reference here https://github.com/reagent-project/reagent/blob/master/docs/InteropWithReact.md#creating-reagent-components-from-react-components
Oh awesome thanks. I see linked from GitHub project home-> tutorials and faq now. Looks like a lot of good stuff there
Any resources on this part? > Take, for example the react-flip-move library and assume that it has been properly imported as a React Component called FlipMove.
@alex-dixon The most reliable options are (1) import using a <script> tag, (2) import using :foreign-libs, (3) use the “double bundle” method with webpack, and (4) use shadow-cljs
shadow-cljs is the clear winner, but you will have to do a little bit of work if you are tightly integrated into a complex build process with lein or boot
this is the double bundle: https://github.com/pesterhazy/double-bundle and these are some notes I took earlier that really should be revised but they still have some examples: https://gist.github.com/jmlsf/f41b46c43a31224f46a41b361356f04d
The double bundle works like a charm for me.
okay i updated my gist on this stuff. should be a bit clearer. it’s helpful to keep in mind that packaging, access, and advanced compilation are all separate concerns. the webpack solution deals with the first two, but not the symbol munging issue. so you’ll either need to use cljs-oops or externs inference if you intend to compile in advanced mode
Good point, thanks!
@lee.justin.m wow thanks. Was not expecting this. Thank you!