{"id":6701,"date":"2014-04-08T10:21:14","date_gmt":"2014-04-08T07:21:14","guid":{"rendered":"http:\/\/railsware.com\/blog\/?p=6701"},"modified":"2021-08-12T17:08:38","modified_gmt":"2021-08-12T14:08:38","slug":"pitfalls-of-rspec-boolean-matchers","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/pitfalls-of-rspec-boolean-matchers\/","title":{"rendered":"Pitfalls of Rspec boolean matchers"},"content":{"rendered":"\n

Rspec provides a bunch of build-in matchers. They include matchers that help us work with boolean values. But not always these matchers are safe to use.<\/p>\n\n\n\n

be_true and be_false matchers<\/h2>\n\n\n\n

I guess everybody used RSpec<\/code> matchers be_true<\/code> and be_false<\/code>. There are a few examples with them:<\/p>\n\n\n\n

# be_true examples\nit{ expect(true).to be_true } # passes\n\n# be_false examples\nit{ expect(false).to be_false } # passes\n<\/pre>\n\n\n\n
but it’s good to know that the following expectations will also pass:<\/p>\n\n\n\n
# be_true examples\nit{ expect(1).to be_true } # passes with fixnum\nit{ expect(\"string\").to be_true } # passes with string\nit{ expect(:symbol).to be_true } # passes with symbol\nit{ expect(\/pattern\/).to be_true } # passes with regular expression\nit{ expect(Time).to be_true } # passes with class\n\n# be_false examples\nit{ expect(nil).to be_false } # passes\n<\/pre>\n\n\n\n
This happens because be_true<\/code> and be_false<\/code> matchers consider nil<\/code> and false<\/code> to be false<\/code> and anything else to be true<\/code>. To make tighter comparison and avoid potential issues use eql<\/code> matcher:<\/p>\n\n\n\n
# eql(true) examples\nit{ expect(1).to eql(true) } # fails with fixnum\nit{ expect(\"string\").to eql(true) } # fails with string\nit{ expect(:symbol).to eql(true) } # fails with symbol\nit{ expect(\/pattern\/).to eql(true) } # fails with regular expression\nit{ expect(Time).to eql(true) } # fails with class\n\n# eql(false) examples\nit{ expect(nil).to eql(false) } # fails\n<\/pre>\n\n\n\n
Predicate matchers<\/h2>\n\n\n\n
Rspec<\/code> provides predicate matchers for each ruby method which ends with ‘?’. For instance, we have a class with method empty?<\/code> which returns true<\/code>:<\/p>\n\n\n\n
Class TestClass\n  def self.empty?\n    true\n  end\nend\n<\/pre>\n\n\n\n
and Rspec file contains:<\/p>\n\n\n\n
it{ expect(TestClass).to be_empty } # passes\n<\/pre>\n\n\n\n
Everything works fine, but let\u2019s do changes in our `empty?` method and return some object instead of `Boolean`:<\/p>\n\n\n\n
Class TestClass\n  def self.empty?\n    'true'\n  end\nend\n<\/pre>\n\n\n\n
and our test still passes even when we return something different from `true`. As `be_true` and `be_false` matchers, predicate matches consider `nil` and `false` to be `false` and anything else to be `true`.
To avoid potentials issues with this behaviour we also should make tighter comparison:<\/p>\n\n\n\n
subject{ TestClass.empty? }\n\nit{ should eql(true) } # fails\n<\/pre>\n\n\n\n
Summary<\/h2>\n\n\n\n
While testing boolean attributes or methods that return boolean value, try to avoid matchers described above.<\/p>\n\n\n\n
UPD<\/strong>
Since RSpec 3 was released, this article is actual for RSpec 2<\/p>\n","protected":false},"excerpt":{"rendered":"
Rspec provides a bunch of build-in matchers. They include matchers that help us work with boolean values. But not always these matchers are safe to use. be_true and be_false matchers I guess everybody used RSpec matchers be_true and be_false. There are a few examples with them: # be_true examples it{ expect(true).to be_true } # passes…<\/p>\n","protected":false},"author":44,"featured_media":9461,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3],"tags":[],"coauthors":["Olexander Paladiy"],"class_list":["post-6701","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"aioseo_notices":[],"categories_data":[{"name":"Engineering","link":"https:\/\/railsware.com\/blog?category=development"}],"post_thumbnails":"https:\/\/railsware.com\/blog\/wp-content\/themes\/railsware\/vendors\/images\/article-thumbnail-default.jpg","amp_enabled":true,"_links":{"self":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/6701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/users\/44"}],"replies":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/comments?post=6701"}],"version-history":[{"count":28,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/6701\/revisions"}],"predecessor-version":[{"id":13998,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/posts\/6701\/revisions\/13998"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media\/9461"}],"wp:attachment":[{"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/media?parent=6701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/categories?post=6701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/tags?post=6701"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/railsware.com\/blog\/wp-json\/wp\/v2\/coauthors?post=6701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}