cleanup support for Rails 2.3 and remove old integration tests

[kares]

mostly just removing unused code/specs

[chadlwilson]

I must admit that I didn’t understand this stuff, however I wondered whether rather than deleting it, it needed to be adapted to rails 6.1 and 7.x to actually run specific rails tests there - which is why I didn’t delete them earlier.

There seemed to be some magic there that looked for these specs if they existed for a given rails version and run them. I somehow had the impression that there were not real tests being run via the appraisals for later versions without such version specific dirs.

But yes, these are definitely unused right now.

[kares]

I must admit that I didn’t understand this stuff, however I wondered whether rather than deleting it, it needed to be adapted to rails 6.1 and 7.x to actually run specific rails tests there

As long as we're talking about the Rails booter specs then than would depend on whether there's changes to the stuff we're adding/overriding.

There's 2 groups (similar to the removed 2.3 group) left here:

describe "Rails 3.x", :lib => :stub do and describe "Rails 3.1", :lib => [ :stub ] do so I think the names are not that great anymore (should be pretty much one Rails group or just flat specs with better descriptions).

The idea around :lib => :stub is we test stubbed regardless of what actual Rails APIs we run.

There seemed to be some magic there that looked for these specs if they existed for a given rails version and run them.

The integration spec mostly has those and there the removed group having :lib => :rails23 meant that pretty much never run. Same logic as before would apply, if we want to test something specific that changes in a given Rails version (against an actual Rails API), than it would be tagged like that.

[kares]

Now having a second look, you're right.

We should have some Rails skeleteon under src/spec/stub based on actual Rails version and use those as a (smoke) "integration" test. And I should also do more cleanup here, since I obviously missed a lot 😜.

[kares]

Managed to remove the Rails stub apps, and also looked into adding back (in a follow-up PR) some based on the Rails versions currently supported.

I have a 7.2 passing tests locally and will setup another one likely for Rails 6.1 (Rails.logger defaults changed between 6 -> 7, so it's worth testing). Unfortunately there seems to be issues matching the appropriate lib: railsXY during a run.

[chadlwilson]

Sorry, missed your comment here. If you can point me to the branch where you're playing with adding back stubs/tests I can take a look and see if I can work it out, as there was some hacking around to do between Maven and rake to get things like that working on modern JRuby earlier. Maybe something similar.

In my my main use case, I haven't been able to get Rails 7.1 working (let alone 7.2) and only managed to move to 7.0 recently after getting jruby-rack fixed via the PRs here, so I have less experience with what has changed on later Rails. I'm very surprised 7.2 actually works via your tests, so that's a good sign.

For future it might be a good idea to have the build fail-fast if it can't find stub tests for a given Rails major/minor version to force us to add them and ensure completeness, if indeed they are important (which I think they probably are to validate something "real" even if we are not validating all manner of servlet containers, logging mechanisms and such).

[jijiNigeria]

Nice