#rspec

codeDude :archlinux: :neovim:codeDude@floss.social
2026-02-06

Hi #ruby community I'm looking for other recommendation here codeberg.org/codeDude/romodoro

I''m not sure how to test this with #Rspec

basically the intention is test if the duration is for example 2 seconds the countdown spend 2 seconds.

Could you gimme ideas please?

#rails #coding #programming #unitTest #softwareDevelopment

2026-02-02

@kerrick And #RSpec.

Whenever I have to use anything other than #Ruby, I am immediately reminded of how every single testing framework is miles, no, light-years behind RSpec.

codeDude :archlinux: :neovim:codeDude@floss.social
2026-01-29

Hello #ruby people, How can I test using #Rspec that accept method is receive(triggered). The class is here codeberg.org/codeDude/romodoro
I having issues trying to mock and stub the dependencies

Rspec code

# frozen_string_literal: true

RSpec.describe Timer::CommandServer do
  let(:socket_server) { instance_double UNIXServer }
  let(:socket) { instance_double UNIXSocket }
  let(:coutdown) { instance_double Timer::Countdown }

  context "when the CommandServer start" do
    it "should accept the connection to the socket" do
      expect(socket_server).to receive(:accept).and_return socket

      allow(socket).to receive :puts
      allow(socket).to receive :close

      command_server = Timer::CommandServer.new socket_server, coutdown
      command_server.start
    end
  end
end
2026-01-23

shoulda-matchers가 실제로 당신을 위해 하는 일

shoulda-matchers는 Rails 테스트 코드를 간결하고 가독성 높게 만들어주며, 모델의 계약을 명확히 문서화합니다.

#rspec #rails_testing
ruby-news.kr/articles/what-sho

three word chant3wordchant@social.coop
2026-01-09

As expected, the ~65% #RSpec test coverage meant that there have been several issues which came up during manual testing, including some very pleasantly head-scratching ones 🧠

2026-01-03

RSpec `have_attributes` 내 복잡한 문자열 검증: `satisfy` 매처 활용

RSpec `have_attributes` 매처 사용 시, 문자열 속성에 대한 복합적인 포함/미포함 조건 검증의 한계점을 제시합니다.

#rspec
ruby-news.kr/articles/rspec-sa

2025-12-26

도쿄 가스의 재난 방지 최전선을 지키는 Ruby: 지진 대응 시스템 SUPREME 사례

도쿄 가스는 Ruby 기반의 SUPREME 시스템을 통해 지진 발생 시 가스 공급을 자동 제어하며 대규모 화재와 폭발로부터 시민들을 보호하고 있습니다.

#rspec
ruby-news.kr/articles/ruby-at-

2025-12-26

hspec uses the same syntax Rspec used many years ago.

Makes me feel nostalgic.

Had to write a spec for some Ruby code recently, turns out instead of function(args).should_equal result one now has to write expect(function(args).to == result.

Oh why?

#haskell #ruby #hspec #rspec

Adam Niedzielskiadamsunday@ruby.social
2025-12-24
Aaron Sumnerruralocity
2025-12-22

🥳 Happy 30th birthday to , still my favorite programming language! Here's a coupon for my book for just $9, with practice advice. Free updates for Rails 8.1 and Ruby 4 coming early next year! Boosts appreciated! 🥳

leanpub.com/everydayrailsrspec

|7eter l-|. l3oling 🧰galtzo@ruby.social
2025-11-29

#mildlysatisfying #rspec4Life #rspec
10591 is the zip code for Tarrytown, NY, the real world setting of Washington Irving's "The Legend of Sleepy Hollow".

Screenshot of RSpec test result reading:
Finished in 22.33 seconds
777 examples, 0 failures
Randomized with seed 10591
Aaron Sumnerruralocity
2025-11-06

This. I've seen a lot of garbage tests this year. I like 's `xit` shorthand for walking more slowly and deliberately through test scenarios, regardless of whether an agent is involved or not.

andy-gallagher.com/blog/stop-v

2025-10-30

TIL in #Ruby #RSpec,

this:

expect(File.exist?(old_file)).to be true

can be shortened to this:

expect(File).to exist(old_file)

expect(File).to exist old_file

Neat!

2025-10-18

@postmodern and also, why doesn't #Ruby itself have an opposite direction of .include? method?

[1, 2, 3].include? 1

Like #Rails’ .in?

1.in? [1, 2, 3]

Then the #RSpec would be:

expect(1).to be_in [1, 2, 3]

Esparta :ruby:esparta@ruby.social
2025-10-16

continuing about collection-based #rspec matchers...

When using `match` and `include` you can let the `it` spec to speak for itself:

```ruby
context 'when one of the values is off' do
it do
expect(subject).to match(
error: 'P',
context: be_a(String).and( eq('S'))
)
end
end
```

I tend to not declare what the `it` is, because it's gratifying see its errors :), usually that's the context blocks are for.

* puns intended
# ruby

An screenshot of my terminal, after running a failed-on-purpose specs:

collection
  when one of the values is off
    is expected to match {error: "P", context: (be a kind of String and eq "S")} (FAILED - 1)

Failures:

  1) collection when one of the values is off is expected to match {error: "P", context: (be a kind of String and eq "S")}
     Failure/Error:
       expect(subject).to match(
         error: 'P',
         context: be_a(String).and( eq('S'))
       )

       expected {:context => " S", :error => "P"} to match {error: "P", context: (be a kind of String and eq "S")}
       Diff:
       @@ -1 +1 @@
       -:context => (be a kind of String and eq "S"),
       +:context => " S",
Esparta :ruby:esparta@ruby.social
2025-10-16

@benjamineskola I'd argue that relying on concrete type is something the spec shouldn't care, at least not in #ruby

For example, perhaps it started with a hash, and that was OK, but later on the team want to change the implementation to use something else, like a Struct class.

Error = Struct.new('ErrorStruct', :error, :context)

error = Error.new('Pusher error', 'oops!')

then `be_hash_including` might fail because it's not a hash, is an Struct. Image having 433 spec files :(

#rspec

Esparta :ruby:esparta@ruby.social
2025-10-16

Lately I've found some resistance to use collection-based #rspec matchers

Checking element by element is technically not wrong:

expect(failure[:error]).to eq('Pusher error')
expect(failure[:context]).to eq('notify_notification_started')

but using `match` & `include` has their advantages:

expect(failure).to match(
error: 'Pusher error'
context: 'notify_notification_started'
)

I can elaborate further if someone ask for it.

Perhaps a blog post about it is needed?

#ruby

A comment in the peer-review tool, where I post my suggestion:

> if this a hash, please use a collection-based matcher:

Suggested change
```diff
-        expect(result.failure[:error]).to eq('Pusher error')
-        expect(result.failure[:context]).to eq('notify_notification_started')
+        expect(result.failure).to match(
+          error: 'Pusher error'
+          context: 'notify_notification_started'
+        )
```
Todd A. Jacobs | Rubyisttodd_a_jacobs@ruby.social
2025-10-13

## Please Don't Nerf RubyLang Because #StyleGuides

Ruby has made some internal changes that remind me of the changes #RSpec made to clean up internals but uglified the code & made certain features simply stop working as expected.

Removing `foo rescue nil` is an exmaple. Some edge cases make this antipattern useful; replacing a one-liner with a complex method/chain is annoying. Mindful chainsaw-juggling gave expert #Rubyists superpowers. Not trusting power users is red #Kryptonite for code.

Red geode, representing the "red Kryptonite" from the Superman mythos that always created odd or undesireable side effects to his powers. It represents the contortions one has to apply to Ruby code as features that were "use at your own risk" are removed from the language's code base.
three word chant3wordchant@social.coop
2025-10-02

One downside of setting myself the stretch goal of "adding #RSPec tests for all URL routes" is that there are a LOT of them 😅

(`rails routes` says 303)

This is of course making this task take forever (~15 hours' work to improve test coverage from ~40% to ~65%).

But, more also-importantly, it's ruining my "lines of code deleted" metric, I have added over 2000 lines of specs alone 🙈

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst