Overarching rspec-rails design guidelines

[Jason Karns]

This second-level question came to mind as I did some digging for documentation in rspec-rails for how the core team determines what rspec-rails supports and what it doesn't.

The initial question is regarding whether rspec-rails should expose support for Rails' TimeHelpers as a first-class module, this thread isn't about that, though. Before opening an issue on the github repo, I wanted to see if there was any documentation that would pre-emptively clarify that this kind of feature request would be received well or whether it was already in contrast to how rspec-rails sees itself.

From my point of view as a _user_ of rspec-rails, my guess at rspec-rails' goal is to: make it possible to use Rails' own testing helpers and terminology within rspec. Wherever a rails test-type exists, there is a corollary in the rspec world (helpers that Rails exposes to a Mailer TestCase for instance, become matchers in :mailer type specs). More broadly than simply type-specific helpers, I would _presume_ that it is a goal of rspec-rails that virtually all Rails helpers have a counterpart in rspec in whatever way makes sense. For example, file_fixture helpers exist and are configured per spec/* instead of test/*; time helpers can be included and used as they would in a rails minitest suite.

My reason for starting this thread is to ask if this "goal" of rspec-rails has ever been written or documented explicitly. A small blurb in a readme or contributing doc would be beneficial. This thread (https://github.com/rspec/rspec-rails/issues/2263) on rails' time helpers in particular seems to imply that there are other "design or architecture" guidelines that factor into rspec-rails' direction; such as whether or not a particular feature in Rails' test helpers contradicts the testing philosphy of rspec's core team.

The comment in question from Jon Rowe: "I'm unsure I want to add this as a default, as I don't personally believe freezing time is a good idea." I might be reading between the lines too much, but this seems to indicate that rspec-rails priority isn't _first_ to faithfully port (as much as possible of) rails test helpers into rspec but in fact has testing opinions of its own that rails' test helpers should align with before being ported into rspec-rails.

It is this fine line that I think would be beneficial if documented somewhere. My own preference of a mission statement of sorts would be that any/all rails helpers should be (as nearly as possible) exposed within rspec; with the end result being that any developer comfortable in a minitest rails suite could assume to find corollaries in a similar rspec rails suite.

Has this kind of thing been discussed before?

[Jon Rowe]

I don’t think it has ever been formalised, but the consensus of the RSpec team since I joined has been that `rspec-rails` is a thin wrapper around Rails test helpers bringing them into RSpec, thus it mostly handles bringing in the same or equivalent modules as Rails, configuring `spec` defaults instead of `test`, and matchers for equivalence with the Rails testing assertions. That has always been the main stay of the support.

For the case of the linked issue, I think my understanding at the time was that this was an optional part of Rails test helpers, if thats not the case it would be a good candidate for bringing in automatically despite any personal opinions on my part.

Updating the read me is certanly something we can look at doing.

Cheers

Jon

--

You received this message because you are subscribed to the Google Groups "rspec" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/c0b89ee1-ce36-4d6f-84e5-d330f81bb702n%40googlegroups.com.

[Marko Avlijas]

Out of curiosity what do you think are downsides of freeze_time?
I like to use it when testing datetime.

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/df0e021b-0c3f-42b7-8553-680832b2c59e%40app.fastmail.com.

[Jon Rowe]

It discourages passing in time as a collaborator, relies on mocking out the real time objects, which can have knock on effects elsewhere in code not under test and can hide timezone bugs (but that last one is pretty minor as the counterpoint is it prevents time flakiness)

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/CA%2Bo2VULeANDKz2q1VtT2iTKRW%2BP4hDJT93hKcWk4G3dmDv1iDw%40mail.gmail.com.