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

Add Javascript testing base class #904

Merged
merged 12 commits into from
Jul 11, 2018
Merged

Add Javascript testing base class #904

merged 12 commits into from
Jul 11, 2018

Conversation

maciej-szlosarczyk
Copy link
Contributor

@maciej-szlosarczyk maciej-szlosarczyk commented Jul 9, 2018

Fixes #900, inspired by false positive from #893 .
A couple gotchas:

  • Since we cannot run these tests in transaction, we need a way to reverse the database after a successful test run. Another option would be to truncate it manually, but that would require us to change how load fixtures. In general we should move away from eager loading all fixtures for all tests, but no need to resolve this issue just yet.
  • Puma is also required to run the test, so moved to :development, :test gem group.
  • Testing depends on Google Chrome and chromedriver. Travis CI is configured properly to run them, new docker images also come with the required software out of the box. @artur-beljajev might need to adjust his dev setup to install required packages. You can use travis configuration and Dockerfile as a configuration guideline.
  • I decided on inheritance, not mixins. So any test classes that need to run javascript and simulate real browser behavior should inherit from JavascriptIntegrationTest.
  • Poltergeist gem is removed, as it was completely unused and we had no rspec tests written that would use javascript.

Can be merged straight to master after it is accepted, since it does not have production impact.

@vohmar vohmar requested a review from artur-intech July 9, 2018 13:27
@@ -0,0 +1,35 @@
require 'test_helper'

class RegistrarSignInTest < JavascriptIntegrationTest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would name it "RegistrarAreaSignInTest", mainly to avoid name clash (I have experienced such clashes before, and it was time consuming to eventually find out that setup/teardown from 2 classes were merged because of the same name of a test class.

end

class JavascriptIntegrationTest < ActionDispatch::IntegrationTest
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth following Rails 5 naming convention http://guides.rubyonrails.org/testing.html#system-testing, given we anyway migrate it.

So to name it ApplicationSystemTestCase instead, and place it into separate file under test dir

Copy link
Contributor

@artur-intech artur-intech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we could avoid using database_cleaner gem. I personally don't have any idea :( (besides doing that gem's work manually, which isn't a good one).

Copy link
Contributor

@artur-intech artur-intech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, how about always run system tests (only them) in the browser? As your example states, we might experience same false positives in the future, unless we run it with JS engine by default.

@maciej-szlosarczyk
Copy link
Contributor Author

What do you mean run system tests with JS by default? Or rather, what do you mean by system test? I find the Rails nomenclature to be completely arbitrary and just made up because they already had used up the integration test name.

In any case, there's a significant performance penalty (3-5 times slower tests, even more) that I think it's a bad idea to do it do it by default, especially since our application uses very little javascript.

@artur-intech
Copy link
Contributor

https://en.wikipedia.org/wiki/System_testing
http://guides.rubyonrails.org/testing.html#system-testing

System tests allow you to test user interactions

Whereas integration tests verify that some parts work together. Seems quite clear for me.

@artur-intech
Copy link
Contributor

artur-intech commented Jul 10, 2018

I fully agree regarding speed, but as I mentioned, if it is not run in a real browser with enabled JS by default (using Rack), there is a chance of exactly same false positive, as we had in #893.

Any other ideas how to avoid such problem in the future?

@maciej-szlosarczyk
Copy link
Contributor Author

I fully agree regarding speed, but as I mentioned, if it is not run in a real browser with enabled JS by default (using Rack), there is a chance of exactly same false positive, as we had in #893
Any other ideas how to avoid such problem in the future?

We have to swallow it and when see an existing RackTest case that should use headless Chrome we should convert them as we do it. Otherwise we would open another can of worms.

In the future, ApplicationSystemTestCase should inherit from
ActionDispatch::SystemTestCase and JavaScriptApplicationSystemTestCase
could possibly be removed if the `driven_by` method works as it is
promised in Rails documentation:

http://api.rubyonrails.org/v5.2/classes/ActionDispatch/SystemTestCase.html

Consider introducing another class between
ActionDispatch::IntegrationTest and other items inheriting from it, as
the general Rails practice seems to have `ApplicationIntegrationTest`,
as we do have `ApplicationRecord` and `ApplicationController`.
@vohmar vohmar merged commit bb98825 into master Jul 11, 2018
@vohmar vohmar deleted the registry-900 branch July 11, 2018 15:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Research and configure javascript testing framework
3 participants