Improve build time for JRuby about super_diff HOT 5 OPEN

Thinking about this some more, it would be cool if we set up a persistent Ruby instance that would start when the test suite starts and shuts down when it exits. That instance could expose some kind of API to load a file and then run that file. That could be a nice way of speeding things up without creating a Frankenstein.

from super_diff.

Take a closer look at how Spring is implemented. I'm thinking we could build something like that — a separate program that sits open on a socket, and when it receives a message it runs some Ruby code and then waits for another message. And when the main program exits it kills the other process.

from super_diff.

Probably something like this piece of code could be used to run arbitrary RSpec tests:

group = RSpec.describe('test') { it { expect(1).to eq 2 } }
runner = RSpec::Core::Runner.new({}, RSpec::Core::Configuration.new, RSpec::Core::World.new)
runner.run_specs([group])

This is based on what is actually used in RSpec:

• https://github.com/rspec/rspec-core/blob/main/lib/rspec/core/runner.rb#L75
• https://github.com/rspec/rspec-core/blob/main/lib/rspec/core/runner.rb#L113

Building new instances of RSpec's Configuration and World are required so that each test is executed in isolation. Without that, each launched example would be persisted and executed in subsequent runs, too.

from super_diff.

Hmm, interesting. Ideally I'd like each test to be fully sandboxed to remove the possibility of global state or, more importantly, be able to replicate specific setups (such as projects that require Rails, projects that only require ActiveRecord, projects that only require ActiveSupport, etc.). I'm worried that being able to run arbitrary tests like that wouldn't fully solve that problem.

from super_diff.

An alternative solution could be following:

• make several spec_helper files, like spec_helper_bare.rb, spec_helper_rails.rb, spec_helper_activerecord.rb, and require (or not) corresponding things in them accordingly;
• mark tests which have to be run under specific setup with RSpec tags;
• with that, you'd be able to run rspec with different setups;
• launch built-on-the-fly examples inside your examples and catch the output.

On the one hand, this goes against "fully sandboxed" approach, because those temporary examples would share the same Ruby env as outer tests of super_diff itself (but another RSpec World). On the other, it would remove the need to spin up a separate Ruby process at all. Thus, you could use it for most of the integration tests (meaning integration with RSpec) to get faster tests; and keep several end-to-end tests with generating temporary apps to get full sandboxing and representativeness.

To clarify a bit what I mean, here's a possible resulting code:

# before
snippet = %|expect(double).to respond_to(:foo)|
program = make_plain_test_program(snippet)
expect(program).to produce_output_when_run(expected_output)

# after
rspec = build_rspec_group { expect(double).to respond_to(:foo) }
expect(rspec).to produce_output_when_executed_inline(expected_output)

RSpec has output matching functionality, it could be used in such setup.

from super_diff.