pepopowitz’s avatarpepopowitz’s Twitter Archive—№ 3,357

  1. …in reply to @housecor
    @housecor A pattern I've picked up from ruby/rails/rspec tests goes one step further with those "after" tests -- anywhere you're tempted to write ....when X happens, that scenario instead becomes another nested describe block.
    On twitter.com Twitter logo pepopowitz’s avatar Mood -1 🙁
    1. …in reply to @pepopowitz
      @housecor In Rspec, you'd reach for the context function instead of describe for those. It's literally the same thing as describe, except for the semantics. A context describes a scenario; a describe describes a thing.
      Permalink On twitter.com Twitter logo pepopowitz’s avatar Mood +1 🙂
      1. …in reply to @pepopowitz
        @housecor so in your example it'd look like describe('auth')... describe('ssr handler')... context('when ensureAuthenticatedThrows')... it('returns 403')...
        Permalink On twitter.com Twitter logo pepopowitz’s avatar ❤️ 1 Favorite Mood +2 🙂
        1. …in reply to @pepopowitz
          @housecor Which I think reads nicely as a story about what's expected! And it also allows you to group tests within contexts, vs repeating those lengthy "...when x happens" names.
          Permalink On twitter.com Twitter logo pepopowitz’s avatar Mood 0
          1. …in reply to @pepopowitz
            @housecor context exists in rspec but it doesn't exist in jest, so I've been using describe to apply to both _things_ & _scenarios_, but I quite like this pattern.
            Permalink On twitter.com Twitter logo pepopowitz’s avatar Mood +2 🙂
            1. …in reply to @pepopowitz
              @housecor I wrote about this and the let block that I wish existed in javascript tests at stevenhicks.me/blog/2021/09/what-javascript-tests-could-learn-from-rspec/. As I wrote there, it's very possible I'm pushing this pattern too far in my tests but hey when is that not the case 😅😬
              Permalink On twitter.com Twitter logo pepopowitz’s avatar ❤️ 1 Favorite Mood 0