This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (6)
- # beginners (110)
- # boot (49)
- # cider (13)
- # cljs-dev (35)
- # cljsrn (5)
- # clojure (145)
- # clojure-conj (3)
- # clojure-dev (60)
- # clojure-italy (2)
- # clojure-nl (3)
- # clojure-russia (3)
- # clojure-serbia (1)
- # clojure-spec (116)
- # clojure-uk (58)
- # clojurescript (235)
- # cursive (14)
- # datascript (7)
- # datomic (31)
- # dirac (144)
- # emacs (1)
- # events (1)
- # hoplon (12)
- # leiningen (11)
- # luminus (60)
- # lumo (19)
- # off-topic (18)
- # om (74)
- # onyx (5)
- # pedestal (13)
- # precept (3)
- # re-frame (3)
- # reagent (15)
- # remote-jobs (7)
- # ring-swagger (25)
- # rum (1)
- # untangled (53)
- # vim (3)
@otfrom we use http://selenide.org/ for our UI testing, certainly a lot better than pure selenium.
but java alas... I had a quick try at calling it from last week, but not really successful unfortunately.
I conducted an experiment about 3 years ago using lein-cucumber (wrapping cucumber-jvm) and then using that to drive selenium. It worked but was clunky. In http://Style.com the QA's wrote all their browser driven tests using cucumber in native Ruby.
Do you think its fair to say that automated front end testing is a almost like a sub project of the project you are testing. I find for it to be useful it has to be well maintained and always updated to the new production code.
my two tips for this are:
(a) Keep the code / tools as close to the rest of the app as you can, the people making the change should be able to update the tests to match and run them locally
(b) Come up with a scheme for the interface between the two, personally I like to use
class="qa-some-identifier" on relevant elements
I'm not saying dont run them or do them, i just think its an interesting thing to think about / discuss
https://martinfowler.com/articles/microservice-testing/ is a decent read on test strategies
I prefer testing against an API as much as possible and using browser driven tests more sparingly and mainly for critical functions.
there was a good line I saw from Chris Ford on twitter the other day, something like: > End-to-end tests tell you a lot when then pass, and little when they fail. Unit tests are the inverse
So in-process interfaces inside something like a SPA can be useful
so i’ll have a few scenarios for end-to-end tests which are user journeys, a smattering of integration tests, and loads of unit tests
I definitely agree with Chris' quote
I feel thinking about how to minimise end to end tests and make them fast tends to be another tool in thinking about how to separate responsibilities in your design
that way a human can spot visual quirks and things which might not fail the release, but are worth patching soon
I also prefer a smattering of manual testing for that reason
Test-time budget is my favourite framework for these decisions though - pick a number like “5 minutes” and don’t let your tests get longer than that
on one project I set myself a budget of 1 second for incremental tests in watch mode
Time to prune tests and rethink where you test (i.e. move tests to API boundaries)
managed to stay under it for months, but it meant I did no integration or e2e tests
I find this impossible where QA exists as a separate function (even embedded in a team) as these E2E tests are what QA does...they tend to want more not less.
Having said that it's rare to find a dev with a testers mind set
in the rare scenario i find myself in an org like that, I mostly ignore that QA team’s test suite day-to-day
Also you have to have been brought in to do that by the right level of management...I find high day rates help with management commitment in these situations too.
we just hit 5 minutes for all out integration tests and that is both API and browser based test.
Hello all, I will be spending more time with my family after this week is over, my family being the Cats, Clojure and Spacemacs. If anyone is interested having me write Clojure code for them, or teach them Clojure, please get in touch.
@jasonbell looking forward to reading yours submissions along with the others we have recieved already.
@jr0cket, when do you start publishing which talks have been accepted? (#eager_beaver)
@yogidevbear we'll announce talks as soon as any are agreed by the organising team. We have already announced Malcolm Sparks, James Reeves and Chris Ford as speakers