Use the REPL, Luke!
(ns cuic.quick-start)
; eval these forms in your REPL
(require '[cuic.core :as c])
(require '[cuic.test :refer [is*]])
(require 'cuic.dev)
(cuic.dev/launch-as-default!)
(c/goto! "https://github.com/")
(c/type! (c/q ".header-search-input") "milankinen/cuic" :enter)
(let [link (c/wait (->> (c/q ".codesearch-results .repo-list-item a")
(filter (comp #{"milankinen/cuic"} c/text-content))
(first)))]
(c/click! link))
(is* (= "CUIC - Concise UI testing with Clojure" (c/text-content (c/q "#readme h1"))))
At one day, one of my colleague came to me asking: "Matti, do you have any tips how to develop our UI tests with the REPL like we do with all other code?" No. I didn't have any. However, I started to think: why does it have to be like that? Why one couldn't just start a REPL, and start developing the UI tests, just like any other code?
The goal of this library is to enable a seamless REPL workflow for your UI tests so that
you can develop and maintain them with smallest possible feedback loop: read-eval-print.
Start a browser with one form, select elements with another and make the browser to click
them with a third one. After you're satisfied with the result, wrap the forms
into a defn
and reuse it in other tests!
Honor native data structures and function composition - CUIC query selectors return a vector of DOM nodes that can be further processed and queried with other query functions:
; visible, enabled input elements under #form
(->> (c/q "#form input")
(filter c/visible?)
(remove c/disabled?))
; text contents of all p elements under #content, concatenated with newline
(->> (c/q "#content p")
(map c/text-content)
(string/join "\n"))
Avoid DSLs. Asynchronous nature of UI testing and all possible race conditions are hard to understand, even without any extra obfuscating DSL.
For a complete reference, see API docs.
TODO
MIT
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close