Fork me on GitHub
#clojure-uk
<
2017-06-22
>
thomas07:06:17

morning šŸ˜¼ mogge

thomas07:06:03

@otfrom we use http://selenide.org/ for our UI testing, certainly a lot better than pure selenium.

thomas07:06:48

but java alas... I had a quick try at calling it from clj last week, but not really successful unfortunately.

thomas07:06:40

but it is very concise and declarative.

agile_geek08:06:02

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.

guy08:06:26

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.

thomas08:06:40

We use cucumber-jvm as well. but the driver is selenide

thomas08:06:42

@guy yes, it is a major piece of work... not something you do on the side.

glenjamin08:06:16

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

guy08:06:48

How do you keep the automated tests quick though

guy08:06:01

the more things you test the slower it gets generally

guy08:06:41

if the tests took say 30 minutes to run, it then becomes almost a blocker

guy08:06:04

I'm not saying dont run them or do them, i just think its an interesting thing to think about / discuss

glenjamin08:06:53

time budget is the best too for that

glenjamin08:06:05

and not being afraid to delete tests that were useful but donā€™t do much anymore

glenjamin08:06:10

or moving them to a different layer

guy08:06:42

interesting thats a good point

guy08:06:26

glenjamin: thanks for the link ill check it out!

agile_geek08:06:44

I prefer testing against an API as much as possible and using browser driven tests more sparingly and mainly for critical functions.

glenjamin08:06:05

by API you mean in-process interfaces, or HTTP API?

glenjamin08:06:52

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

agile_geek08:06:58

So in-process interfaces inside something like a SPA can be useful

glenjamin08:06:24

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

agile_geek08:06:25

I definitely agree with Chris' quote

guy08:06:40

if you only test a few user journeys, why not just manually test it?

glenjamin08:06:59

via a script (in the storytelling sense)

agile_geek08:06:17

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

glenjamin08:06:22

that way a human can spot visual quirks and things which might not fail the release, but are worth patching soon

agile_geek08:06:49

I also prefer a smattering of manual testing for that reason

glenjamin08:06:07

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

glenjamin08:06:28

if you get the near the threshold, itā€™s time to take stock of current inventory

glenjamin08:06:53

on one project I set myself a budget of 1 second for incremental tests in watch mode

agile_geek08:06:59

Time to prune tests and rethink where you test (i.e. move tests to API boundaries)

glenjamin08:06:14

managed to stay under it for months, but it meant I did no integration or e2e tests

glenjamin08:06:28

but my iteration speed was great

agile_geek08:06:53

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.

agile_geek08:06:21

Having said that it's rare to find a dev with a testers mind set

glenjamin08:06:55

in the rare scenario i find myself in an org like that, I mostly ignore that QA teamā€™s test suite day-to-day

glenjamin08:06:20

if itā€™s a gate, iā€™d try and get QA/dev more joined up

glenjamin08:06:31

but organisational change is hard unless youā€™ve been brought in to do that

agile_geek08:06:32

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.

guy08:06:45

thanks for the tips folks

thomas08:06:20

we just hit 5 minutes for all out integration tests and that is both API and browser based test.

practicalli-johnny09:06:45

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.

guy09:06:05

:thumbsup:

jasonbell13:06:44

@jr0cket <<the deadline for ClojureX proposals is the 17th July>> Thank you.

practicalli-johnny13:06:55

@jasonbell looking forward to reading yours submissions along with the others we have recieved already.

yogidevbear14:06:06

@jr0cket, when do you start publishing which talks have been accepted? (#eager_beaver)

practicalli-johnny15:06:20

@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