@pvillegas12 I have a lot to say on testing, and I’ve said it in talks and many other places…some online, some here. I personally think UI-layer testing is mostly a waste of precious developer time. Wilker’s approach is the best I’ve seen for insuring your components won’t throw exceptions when in the wild, which is mainly what you should care about…visual “jankiness” typically has: low effect on end user, is easily reported and fixed, is constantly in the developers face while developing, and any kinds of tests around them usually fail a lot more for bad reasons than useful ones. I would never pay a dev $90k+ a year to write them. I think the cost/benefit ratio is waaaay too high for all but the most sensitive scenarios (e.g. the UI having a glitch threatens someone’s life)

What about acceptance tests? Ones that exercise the entire application (both backend + frontend)?

If you actually measure the time spent on those tests in real $$$ for dev costs vs. the real $$$ benefit of them (or even the $$$ risk), I think you’ll come to the same conclusion. Are you going to lose a customer over a UI glitch? How often do those glitches happen? Do they usually make the software unusable? I’ve been doing this a long time, and the answers I’ve found are: - never, unless it sucks really badly…but that isn’t fixed by tests - rarely. - rarely.

Depends. If it’s a REST endpoint with clear specs, then an acceptance test is easy, cheap, and great.

If you’re trying to run your UI in a full-stack deployed scenario for acceptance…never seen that pay off in automation.

never

not even CLOSE

Now, I will write a very small number of smoke tests that try to prove the system is “up”

those are useful for automated monitoring

and that does pay off quickly

or at least cover the major use cases

the permutations can go at the unit test level

proving a system “correct” from the outside is a costly, futile effort

If you’ve hit spots that exercise the major components, that’s enough

got a schedule system that runs on the back-end..you need to do something that hits it

yes, major system checks

proving network connectivity is right, etc.

but not really proving anything about the software itself…these are system integration tests

“can I talk to the db?”

that kidn of thing…but yes, through the UI so you know the whole stack is working

what kind of tests do you do for your components then?

and for that you’re gonna need a driver that can run the thing with js etc

low-level components? None.

people are playing with them 24/7…

they rarely if ever break, don’t cause much of a problem if they do (usually a css glitch that you can’t catch anyhow)

waste of time

I mean, you use the darn thing quite a bit while designing it don’t you?

and if you change it in any significant way, your tests would all mostly break…

But I encourage you to actually do the math..good testing is a balance of a technique that can help you, with real costs. You can get quite good coverage effectively…but don’t waste your money where it doesn’t do so

What I perceive is that I would test lower lever functions that the component uses, not particularly the dom rendering

your rendering is pure

if the state is right, the rendering is likely to be so as well

so, if you’ve testing your state manipulations, you’re covering what really counts

one of the problems with dynamic languages, though, is that you lose the connection between tests of state and the requirement of the component

this is where clojure spec can help

IMO if you’re going to write tests around state, then you also need specs that are checked during dev

can you explain the connection better?

So, in a typed language, you might say “this UI component takes a PersonLineItem”

the compiler will verify that that’s what you actually pass to it

your tests on state would make up instances of PersonLineItem…they’d test what they’re putting in

now the compiler and type system has checked that the two have a logical connection

in languages without a static type system, you’re throwing around bags of data

so your tests might prove that the person line item “map” has a :foo in it, but the component might actually want :bar

they’re not logically checked for connection by a compiler

With specs you can also generate the test data

like @wilkerlucio said

right, so you would make dev-time checks that what the component receives is correct?

well, if you follow Wilker’s approach, you’d run generative tests on the UI component to the same specs your state manipulations do with it’s state

I mean, for stateful components, there is a check between query and what you destructure in props right?

if you use the non-lambda version of defsc options, yes

it’s not a spec check, but you can trust the query as a result of that

and the query has the props you can spec

how would you run the spec at devtime?

if you wanted to, you could just use (s/valid? ::spec props) in your component near the top with some kidn of logging

I encountered this with mutations, I wanted a precondition to hold (one could use spec here) but I got forced to do that in the mutation* version

and if you surrond those with (when js/goog.DEBUG ...) they’ll get dropped by DCE for release builds

This same approach applies to mutations as well? I have some mutations that use certain arguments for local changes and others for the remote

(thinking about the file upload part)

I wanted to check the required keys I wanted on the params map

@pvillegas12 this is the "magic" for the check-component 😉 https://gist.github.com/wilkerlucio/3d0846d106f992bff7c7e49ea6f580c2

there is missing component initialization here, I omited because that requires tons os local code to reason about

but its just about getting props from line 17 and mixing with your initial state

Hi, Working on a routing library for fulcro. Currently I'm adding a protocols to defsc, but thinking that it could have a nicer interface if implemented as a macro that generates the defsc macro 😅. Does anybody have some code that does something similar and could help me out with an example ? What I'm going for is something like:

(defsc-route MainPage [this props]
  {:query         [:prop1]
   :ident         (fn [] [:page/main :singleton]) 
   :initial-state {:prop1 true}
   :route-entered (fn [component]
                     (js/console.log "router Entered"))}
  (dom/div "Page content"))
  
  
; results in ->

(defsc MainPage [this props]
  {:query         [:prop1]
   :ident         (fn [] [:page/main :singleton]) 
   :initial-state {:prop1 true}
   :protocols     [static
                   Routing
                   (route-entered [this]
                     (js/console.log "router Entered"))]}
  (dom/div "Page content"))

@claudiu do you have anything visible yet? I would definitely like a routing library that mimics the Ember router (which has been copied in other projects, the API is quite good for major use cases). Right now there is a lot of repetition on defining routes with html5 support

@claudiu so the defmutation macro is probably the easiest to read as an example…defsc itself it a very large thing because of all of the error checking and such it does…Basically, I recommend writing specs for your syntax, using those to pick the bits you want apart, and then emit a normal defsc.

like you’re suggesting

The defsc macro has some bits that would be useful to you, like arity-checking on the lambda form

@tony.kay yep love the defsc macro checking stuff. Just want to wrap it up in something that's easier on the eyes and implements the protocols stuff on top. This will be the first macro I write, was hoping somebody did something similar and I can just copy/paste adjust and continue on the other parts of my mini project. 🙂 Will take a look at defmutation 🙂

https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/primitives.cljc#L2696

The build-ident helper does the morphing of the :ident option…it’s probably the simplest

actually, since you’re trying to add an option that turns into a protocol…there’s a nice generality there that might be useful for others

we could probably build a macro called something like extend-defsc that could be used to create a macro that does this transform

yep. Think I need to add more than 1 protocol actually 😞 Since I want to add optional methods and looks like in cljs there is no nice way to check if a method of a protocol is implemented. Need to look at it a bit more but last time I could not find a nice way to do that

that sounds like a really useful macro to have 🙂 will give it a shot

I can throw a quick example together and perhaps you can refine it?

seems like a good one for incubator

fork incubator and I’ll add a starting point in the feature/extend-defsc branch

awesome 🙂 thank you 🙂

@claudiu https://youtu.be/mXcxTQnwIM4 should be up in 2-3 minutes…part one of a macro tutorial

Part 2 is coming @claudiu. I ended up with a fully-working macro, spent more time than I had, though…but at least we have some macro videos to help others now.

https://youtu.be/0Ityz2SHQOA