Add regression tests for existing frontend functionality

[kimadactyl]

User story

As a developer or project owner, I need to understand what the frontend is meant to do, in order that I can reason about changes to it and prevent things that work now from breaking.

Acceptance criteria

• There is a BDD test suite that describes the desirable functionality
• Events have their behaviour described in tests
• Partners have their behaviour described in tests
• Sites have their behaviours described in tests
• Project README is updated to reflect the testing idiom

Implementation notes & questions

Proposal is to set up a Spinach test suite that describes the functions. @pedantic-git's https://github.com/fishpercolator/name.pn/ repo has an example how to do this. We would then seek to replace our current shaky integration testing with proper Cucumber-y tests.

Implementation plan

To be written by the developer

[pedantic-git]

LMK if you need any specific Spinach or Capybara tips when this work gets underway.

[kimadactyl]

LMK if you need any specific Spinach or Capybara tips when this work gets underway.

Ahh thankyou! The main thing I could maybe use your eyes on is our Capybara config. This does not look like a happy test suite to me - a pragmatic solution to something that perhaps shouldnt be there.

https://github.com/geeksforsocialchange/PlaceCal/blob/main/test/system_test_helper.rb#L24-L44

I think a lot of this has to do with Select2 still loading from JQuery. Do you have a gut feeling if this a Select2 problem, or Selenium, or other?

[pedantic-git]

Oh yeah I think this is a classic Capybara gotcha that catches everyone when they first start. The rule with Capybara is "if you think you have to write your own waiting code, you don't".

Where it usually catches people is when they do something like this:

input = find('input.blah') # This blows up if input.blah hasn't appeared yet
# ... eg. input.send_keys 'Hello'

Here you don't need to write your own waiting code to wait for the input to appear - you can just add another assertion before it:

expect(page).to have_css('input.blah') # This will wait for the default timeout - usually 5 seconds - for the element to appear before it considers the assertion to have failed
input = find('input.blah')
# ...

You can increase the timeout on assertions that are expected to take a long time (e.g. if there's a whole page with millions of images loading!), with the :wait parameter:

expect(page).to have_css('input.blah', wait: 10)

And regarding select2 - although I think it's a separate issue - I've found the brilliantly named Tom Select to be an almost drop-in replacement that can be used directly in Stimulus without any JS dependencies.