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)
On Fri, 30 Jun 2023, at 8:58 AM, Marko Avlijas wrote: > Out of curiosity what do you think are downsides of freeze_time? > I like to use it when testing datetime. > > On Fri, Jun 30, 2023 at 9:51 AM Jon Rowe <[email protected]> wrote: >> __ >> 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 >> >> On Thu, 29 Jun 2023, at 5:56 PM, 'Jason Karns' via rspec wrote: >>> 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? >>> >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/rspec/c0b89ee1-ce36-4d6f-84e5-d330f81bb702n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/rspec/c0b89ee1-ce36-4d6f-84e5-d330f81bb702n%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rspec/df0e021b-0c3f-42b7-8553-680832b2c59e%40app.fastmail.com >> >> <https://groups.google.com/d/msgid/rspec/df0e021b-0c3f-42b7-8553-680832b2c59e%40app.fastmail.com?utm_medium=email&utm_source=footer>. > > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rspec/CA%2Bo2VULeANDKz2q1VtT2iTKRW%2BP4hDJT93hKcWk4G3dmDv1iDw%40mail.gmail.com > > <https://groups.google.com/d/msgid/rspec/CA%2Bo2VULeANDKz2q1VtT2iTKRW%2BP4hDJT93hKcWk4G3dmDv1iDw%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/a336ce44-a2de-41ee-a05c-6aab39fbf77e%40app.fastmail.com.
