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

Spec Fixes + Rails 5 Rough Edges #388

Merged
merged 17 commits into from
Nov 22, 2016
Merged

Spec Fixes + Rails 5 Rough Edges #388

merged 17 commits into from
Nov 22, 2016

Conversation

toastercup
Copy link
Member

@toastercup toastercup commented Nov 18, 2016

This is a very large PR (with many side-effect changes) with a few significant changes, so I'm fine debating and letting this one sit for a bit. Namely, the Rails 5 defaults, the rebuilt test harness (the documentation from rspec/rspec-rails is light on how to require these files properly), and the ES changes are all things I want to do more research on before a merge. Either way, this gets specs passing on Semaphore again! Details:

  • Upgrade Elasticsearch, remove unnecessary extensions and config options, ensure seeding doesn't happen twice, add ONET and Custom Content seeding, re-arrange bower setup, install bower devDependencies for test running, tweak sleep time
  • Create Rails 5 ApplicationRecord abstract class, use dotenv-rails to load environment variables even earlier, use Rails 5-compatible awesome_nested_set, add missing User/has_many/Posts association, remove old Mongo-related code, switch new_framework_defaults to Rails 5 defaults (an optimistic decision; potentially premature), eager_load Rails for test environment in environment config rather than test setup
  • Use Redis as the session_store, which should eliminate cookie errors we're seeing in New Relic on Production, and potentially speed things up, as well
    • New SESSION_STORE_URL env variable now required
  • Add missing_indices migration from acts_as_taggable_on
  • Fix broken migrations by ensuring FactoryGirl lazy-loads hardcoded class references; reference new cortexcms.org domain; utilize recommended ApplicationJob abstract class; remove unused tenantUsers scope; remove client_skips_authorization? assumptions - no longer needed; set AR generators to use UUID PKs by default
  • Fix API Documents spec
  • Fix a bunch of specs by using FactoryGirl's build strategy instead of create, which doesn't persist factory to AR/ES; should speed up specs; these UserAbility specs aren't testing persistence, just authorization, so this is reasonable
  • Mark a couple tests pending and document why
  • Use rspec gem to execute specs instead of rake task, per their documentation, for semaphore; this actually is running many more spec files now
  • Fix up spec_helper require statements; fix Simplecov coverage report generation
  • Completely refactor test harness, add @ElliottAYoung's coverage improvements
  • Add .rspec for pretty colors!
  • Switch to HTTPS git URIs, per bundler warnings
  • Fix ES on Semaphore by letting ES start and stop itself
  • Implement MDL Flash functionality
  • Switch to jquery v3

…ns, ensure seeding doesn't happen twice, add ONET and Custom Content seeding, re-arrange bower setup, install bower devDependencies for test running, tweak sleep time
…load environment variables even earlier, use Rails 5-compatible awesome_nested_set, add missing User/has_many/Posts association, remove old Mongo-related code, switch new_framework_defaults to Rails 5 defaults (an optimistic decision; potentially premature), eager_load Rails for test environment in environment config rather than test setup
…ass references; reference new cortexcms.org domain; utilize recommended ApplicationJob abstract class; remove unused tenantUsers scope; remove client_skips_authorization? assumptions - no longer needed; set AR generators to use UUID PKs by default
…which doesn't persist factory to AR/ES; should speed up specs; these UserAbility specs aren't testing persistence, just authorization, so this is reasonable
@@ -0,0 +1,2 @@
--color
--require spec_helper
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd suggest being explicit in the files requiring spec helper instead of this.

Copy link
Member Author

Choose a reason for hiding this comment

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

👍 I was unsure about this - the docs conflicted themselves in a couple spots. Moving this out of .rspec.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure there's any real NEED either way. But I feel .rspec is better for personal configurations imo.

Copy link
Member Author

Choose a reason for hiding this comment

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

Blah.. upon looking into it more, getting rid of this means we have to have require statements one very one of our specs. I'd rather favor a global configuration like .rspec to handle this tedium..

@@ -11,7 +10,7 @@
# Do not eager load code on boot. This avoids loading your whole application
# just for the purpose of running a single test. If you are using a tool that
# preloads Rails for running tests, you may have to set it to true.
config.eager_load = false
config.eager_load = true
Copy link
Contributor

Choose a reason for hiding this comment

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

As the app gets bigger, this is gonna really slow down your specs, making it harder to run them locally.

Copy link
Member Author

Choose a reason for hiding this comment

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

This is part of a larger attempt at making coverage more accurate across our applications - Elliott could speak more to this, but we're eager loading so that Simplecov is aware of all the LOC of our application. Without this, it misses a few files and gives a higher coverage %.

Here's the relevant PR from Employer: https://github.com/cbdr/employer/pull/551
I'm waiting to pull some of this functionality in to fix up some namespacing and turn some stuff into modules.

Copy link
Member Author

Choose a reason for hiding this comment

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

To address the concern - yeah, it's definitely going to slow this down. My only thought is we could re-introduce Spring.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah.

We just solved this by having good code coverage 😆

Capybara.register_driver :poltergeist do |app|
Capybara::Poltergeist::Driver.new(app, js_errors: false, timeout: 900.seconds)
end
require 'rails_helper'
Copy link
Contributor

Choose a reason for hiding this comment

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

rails helper is requiring spec helper already, so this is circular. Don't think it hurts for requires, but you might as well merge them into one file in that case.

The general advice I've seen is rails_helper should be for feature specs/rspec-rails specs, while the spec_helper is for independent classes (services, interactors, anything that doesn't depend on the rails stack).

Copy link
Member Author

Choose a reason for hiding this comment

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

👍 fixing the require statements here. I think I've mostly followed that pattern; Rails-y things are in the rails_helper. I think there's a couple things I could tighten up in spec_helper, though. Thanks for your help and second pair of eyes!

SMTP_SENDER_DOMAIN=cbcortex.com
SMTP_SENDER_ADDRESS=noreply@cbcortex.com
SMTP_SENDER_DOMAIN=cortexcms.org
SMTP_SENDER_ADDRESS=noreply@cortexcms.org
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we own cortexcms.org?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ayep! See: docs.cortexcms.org

@@ -144,7 +144,7 @@ $ npm install -g bower && bundle exec rake bower:install:development
* Create databases:

```sh
bundle exec rake db:create:all
$ bundle exec rake db:create
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a personal preference more than anything, but could we not have "$" at the start of the command lines in the README? It means I have to drag copy rather than double click...and you know...saving precious seconds and all

Copy link
Member Author

Choose a reason for hiding this comment

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

I was going to agree with you, but I dug into the top trending/open source repos on Github, and they all follow the $ convention. This is because occasionally, one may want to include the stdout output in the highlighted code block, and $ makes clear that you're going to be typing that expression as input into a shell prompt that expects it. I still want to dig into this more and see who avoids $'s, and maybe poke some people on IRC about it. Thanks for the suggestion, though - I certainly get annoyed by it when I'm copying/pasting commands from a readme.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ugh - life is hard and the struggle is real

Copy link
Contributor

@ElliottAYoung ElliottAYoung left a comment

Choose a reason for hiding this comment

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

I've nitpicked and mourned the loss of the Marquee, but it looks good to me 👍

This was referenced Nov 22, 2016
@toastercup toastercup merged commit f91181e into develop Nov 22, 2016
@toastercup toastercup deleted the semaphore-build-fixes branch November 22, 2016 17:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants