Speeding Up Specs in core_models

# Speeding Up Specs in core_models ### Questions: 1. What tools can we utilize to help us identify slow specs? * We already had metrics in the app that tagged the slowest specs. See below for more details. 2. Are there any specs that stand out as particularly slow? * I could not identify any that stuck out. See Notes section below for more details 3. What tools can we utilize to help us diagnose why specs are slow? * There are several, all of which I've outlined in the doc below. Specifically, test-prof and the provided playbook can certainly help. 4. What tools can we utilize to help us prevent the introduction of slow specs? * We could do something like [this](https://stackoverflow.com/questions/35805043/how-to-fail-or-continue-to-next-rspec-test-after-n-seconds), but we run the risk of introducing even more flakiness on the master branch. * as of 3/29, core_models contains: * `10633 examples, 0 failures, 14 pending` * we'd have to set the standard of 8 seconds per spec if we wanted to get down to 25 seconds * We could also piggy-back off of [this repo](https://github.com/notlfish/rspec-linter) to make our own linter to help enforce some of the guidelines that we're establishing here. 6. Are there any "quick wins" that can help us increase spec time without going through the core_models suite on an individual basis? * The test-prof playbook is all about helping to identify these kinds of things. 8. What is the proposal for a game plan to help increase core_models spec speeds in Q2? * See recommendations below. What we commit to can be based on bandwidth. ### Notes https://nitro.powerhrg.com/runway/backlog_items/HFH-2013 * the first thing that I notice is that we don't have any specs in core_models that have runtimes that stand out from the rest. we have a bunch of specs that can take a long time. One run was reporting specs in the 60+ second for individuals, another was reporting specs with top run times of 17 seconds. * one thing we could do to address this is to add a linting / ratchet system to automatically fail specs that take longer than x amount of time. There are lots of pros/cons to this, we'd have to discuss. * [DONE] another issue: if they're reporting specs with such wildly different times, why are they in our CI to begin with? * we can turn them off with: * config.profile_examples * and the simplecov stuff defined in rails_helper * early metrics indicate this may save some time * Since we're getting a lot of varied results on which specs are slow, part of our plan should be to find ways we can apply blanket changes * [DONE] we should also consider removing these results from CI outputs (and not tracking them at all in CI, especially if it saves time) ### Recommendations for the Suite 1. audit / optimize helpers * `components/core_models/spec/spec_helper.rb` & `components/core_models/spec/rails_helper.rb` * based off of [recommendations from this article](https://thoughtbot.com/blog/debugging-why-your-specs-have-slowed-down#identifying-slowdowns-in-the-spec_helper) * I see some `before` and `after` blocks that could potentially get cleaned up * We could use the [before_all](https://test-prof.evilmartians.io/recipes/before_all?id=before-all) call 2. Don't include Rails in every test * based off of recommendations from [here](https://rubytab.com/blog/rspec-increase-speed-of-slow-tests/#do-not-include-rails-in-every-test) * the idea is to start off using the more lightweight spec_helper, and then move to rails_helper only when it's needed * we'd have to also audit these files to make sure things are included in their proper places 3. [Analyze factories with test-prof](https://rubytab.com/blog/rspec-increase-speed-of-slow-tests/#analyze-your-factories) 4. Consider using [EvilMartians](https://evilmartians.com/chronicles/test-prof-3-guided-and-automated-ruby-test-profiling) -- they literally wrote the profiler for this and have had gigs focused solely on speeding up test suites * this has multiple steps for helping to get things to run faster: 1. General profiling 1.1 Application boot profiling 1.2 Samping tests profiling 2. Narrow down the scope 3. Specialized profiling 3.1 Dependencies configuration 3.2 Data generation 4. Factories usage 4.1 Factory defaults 4.2 Factory fixtures 5. Reusuable setup ### Recommendations for Individual Specs 1. [Guard against excessive db calls](https://thoughtbot.com/blog/debugging-why-your-specs-have-slowed-down#safeguarding-against-future-slowdowns)