Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup database before starting the browser in tests #4472

Merged
merged 7 commits into from
Apr 14, 2021
Merged

Conversation

javierm
Copy link
Member

@javierm javierm commented Apr 13, 2021

References

Objectives

  • Make tests more robust
  • Make tests easier to read
  • Reduce the number of useless requests in system tests

@javierm javierm added the Specs label Apr 13, 2021
@javierm javierm self-assigned this Apr 13, 2021
@javierm javierm added this to Reviewing in Consul Democracy via automation Apr 13, 2021
We forgot to remove these lines in commit da121eb.
Just like we did in commit 0ec8878, we remove the useless initial
request in the `before` filter since most tests started by visiting a
different URL.

We also reduce the risk of database inconsistency which comes with
setting up the database after the browser has been started.
We were adding a `visit` in a `before` block but then we started the
search tests with another `visit`.

We also created records in the database in between, which increased the
risk of database inconsistency since the process running the browser had
already been started.
Changing the database after the process running the browser has started
is proving to be one of the reasons tests are failing sometimes, so
we're reducing the number of times were that happens. In this case, we
were changing a setting.
We were updating the database after starting the browser to emulate the
behavior where a user logs in a day before the current request. We can
use `current_sign_in_at` instead and devise will automatically copy that
value to `last_sign_in_at` after users visit a page.

This way we avoid setting up the database after the process runnin the
browser has been started.
We were adding a `visit` in a `before` block but then we started some
tests with another `visit`.

We also destroyed records in the database in between, which increased
the risk of database inconsistency since the process running the browser
had already been started.

Besides, some tests were wrong; they were visiting a page with the
browser, then destroying records in the database, and then checking the
page without reloading the browser. Since we aren't automatically
refreshing the affected areas of the page, obviously the page content
before and after destroying records is exactly the same, and the test
was passing because it's testing content that isn't there in any
situation.
@taitus taitus self-assigned this Apr 14, 2021
Consul Democracy automation moved this from Reviewing to Testing Apr 14, 2021
@javierm javierm merged commit 89e8292 into master Apr 14, 2021
Consul Democracy automation moved this from Testing to Release 1.3.0 Apr 14, 2021
@javierm javierm deleted the visit_after_setup branch April 14, 2021 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants