69e5ebc777
and apply new cop 99% Style/SuperArguments and a couple Layout/EmptyComment and Style/ArgumentsForwarding that are found by fixes in those cops Change-Id: Icc0af9c8065f035bca43868b564f73e8776052f2 Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/348626 Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com> Reviewed-by: Jake Oeding <jake.oeding@instructure.com> QA-Review: Cody Cutrer <cody@instructure.com> Product-Review: Cody Cutrer <cody@instructure.com> Build-Review: Cody Cutrer <cody@instructure.com> |
||
---|---|---|
.. | ||
activesupport-suspend_callbacks | ||
acts_as_list | ||
adheres_to_policy | ||
attachment_fu | ||
autoextend | ||
bookmarked_collection | ||
broadcast_policy | ||
canvas_breach_mitigation | ||
canvas_cache | ||
canvas_cassandra | ||
canvas_color | ||
canvas_crummy | ||
canvas_dynamodb | ||
canvas_errors | ||
canvas_ext | ||
canvas_http | ||
canvas_kaltura | ||
canvas_mimetype_fu | ||
canvas_panda_pub | ||
canvas_partman | ||
canvas_quiz_statistics | ||
canvas_sanitize | ||
canvas_security | ||
canvas_slug | ||
canvas_sort | ||
canvas_stringex | ||
canvas_text_helper | ||
canvas_time | ||
canvas_unzip | ||
config_file | ||
csv_diff | ||
diigo | ||
dr_diff | ||
dynamic_settings | ||
event_stream | ||
google_drive | ||
html_text_helper | ||
i18n_extraction | ||
i18n_tasks | ||
incoming_mail_processor | ||
json_token | ||
legacy_multipart | ||
live_events | ||
lti-advantage | ||
lti_outbound | ||
paginated_collection | ||
plugins | ||
request_context | ||
rubocop-canvas | ||
stringify_ids | ||
tatl_tael | ||
turnitin_api | ||
utf8_cleaner | ||
workflow | ||
README.md | ||
gemfile_prefix.rb | ||
test_all_gems.sh |
README.md
Gems
This folder is a place to extract modular functionality from canvas. Canvas's Gemfile arrangement is enabled to read gems from this path locally without installing from a remote source. This is valuable for a few reasons:
- it prevents circular dependencies (bundler won't allow it)
- modularized code cannot bind to specific domain concepts on canvas models
- gems can have their specs run independently, without needing to load all of canvas, saving iteration time
- it allows for eventual build optimization via only running specs for the transitive closure of parents depending on a gem where a change is.
There are some tradeoffs:
- spreads canvas over more subdirectories, giving some mental overhad to traversing the entire codebase.
- modular tests necessarily don't test integration with canvas concepts, so solid integration tests in the app are still a requirement.
- total SERIALIZED build time goes up because each gem loads it's specs in a new process rather than all running within an already booted canvas process.
[TODO] eventually write more on whether we feel like those tradeoffs are good ones, and what the best practices are to leverage this pattern for max-gain/min-pain.
Testing
To test all the gems:
cd gems
./test_all_gems.sh
To test an individual gem
Run ./test.sh
inside the gem's folder. This is basically the same as:
cd gems/google_drive
bundle
rspec