Clojurians Log v2

When using etaoin, what’s the best way to debug cases where an element can’t be found and I think it should be? In my case my tests work well up to a particular point, and then etaoin says it can’t find an element based on criteria that I’m sure are correct. I’m using the firefox driver.

I managed to figure out my problem (apostrophe in the text I was trying to match) but my problem remains - when the xpath is invalid there seems to be no error of any kind. Is it possible to validate xpath in etaoin before using it?

@cfleming: I think the best way I’ve found is to drive your etaoin tests when writing them and debugging via a REPL with a headed browser. It makes browser testing a joy, when you can use the browser itself to see the DOM and you can watch the tests execute. Screenshot or println debugging via a browser is a nightmare.

e.g. I have a rich comment block at the bottom of each of my tests that contains:

(def driver (et/chrome (assoc h/default-driver-config
                                :headless false)))

(def system (h/load-project-test-system :cogs (test-profile)))

(deftest my-tests
    (h/with-system system (h/load-project-test-system :customer-name (test-profile))
      (h/with-web-driver driver
         (some-test-scenario driver system))
         (some-other-test-scenario driver system))))

Yeah, that’s what I came back to. In my tests I was closing my browser instance in a finally block, but for dev I just stopped doing that and then I can poke around when things don’t work. It’s a lovely experience all round.

The xpath thing was annoying, but I can live with that.

Yeah

REPL driving browser tests is great — otherwise it’s a total nightmare. In the kaocha command line and ci we run them headless

Yes, no doubt.

There is also babashka integration for etaoin which allows you to use it in scripting: https://github.com/babashka/pod-babashka-etaoin

(I've used this to create a file watcher and reload a browser to view my re-rendered asciidocs)

In the JVM REPL I use the same workflow, define a global browser and then poke at it, until it works

Yeah, that’s what I’ve been doing so far, especially once I ditched the closing in the finally block.

Yeah I was struggling with etaoin for a while until I figured that workflow out… Then it became much more pleasant.

(btw, here's a demo of the filewatcher + etaoin thing: https://twitter.com/borkdude/status/1268270628039282690)

@cfleming are you working on a web version of Cursive? 😉

Haha, no, but my licensing is all CLJS on AWS.

:thumbsup: Neat

The whole thing was a bit of a mess held together with blu-tack and sticky tape, and I’m tidying it all up.

Anyway I came here to ask a question… I’ve found that etaoin doesn’t really encourage you to make assertions, as you typically call et/wait-predicate or some variant for a condition to be true, and if the wait times out you get an exception not an assertion failure. If you then want to add an explicit assert it’s one or more extra lines essentially repeating the query from inside your wait, and wrapping them in an (is ,,,) form. This means I sometimes ignore making assertions; which I don’t particularly like; but for some tests I find the extra verbosity of writing the tests such that assert works properly is a bit annoying. I guess I could write some macros to dry this up… but I was wondering what other people were doing with regards to this.

I’ve been using etoain since the day before yesterday, so this needs a pinch of salt obviously.

But I’m not using a test framework at all, and I just have a script which I run. If there are no exceptions, then everything is good 🙂

Actually, that’s not quite true, I have it broken down into a couple of functional groups, basically by the page under test. Those are top-level functions, and I just invoke those from comment blocks. So I can run separate parts of the tests separately.

I actually did use deftest and then did all the etaoin stuff within a test. So when an exception happened, that test fails

But no is - well, some, for like checking if a downloaded file exists, etc.

Ok so people are basically doing the same

Yeah quite a few tests do use is but many don’t.

FWIW I use a Swing GUI driver similar conceptually to etaoin to generate the screenshots for my docs, and I do the same there. I think it works well for this type of thing.

We even used https://github.com/xebia/VisualReview to make visual diffs of screenshots, although that was often brittle.

I ran into an issue today though where kaocha annoyingly elides printing testing blocks if they don’t have any assertions in them, and clojure.test prints an error about deftest containing no assertions too 😞

clojure.test doesn't do that by default though

ahh right enough it’s probably cider printing the later

I did make a lib which does that: https://github.com/borkdude/missing.test.assertions

yeah, cider does that for you

The thing I dislike about not explicitly making assertions is that it becomes hard to read what the test actually is without them… i.e. it doesn’t cleanly distinguish trying to get into a state from what the desired state should be.

well, you could of course write (testing "foo" (etaoin/....) (is :succeeded))

that’s exactly what I’ve been doing as a work around

Anyway that’s useful to know I just popped in here to double check I wasn’t doing it wrong, after noticing kaocha wasn’t printing my assertions ( https://clojurians.slack.com/archives/CCY2V0U6A/p1593165322352600 )

@rickmoynihan Btw, maybe you could make an assert-expr multi-method implementation to deal with this

ahh that’s actually a good idea

(is (working ....)) 😉