DRY and attr_(accessor|writer|reader) methods with rspec

[Tom Hale]

I'm quite surprised that there's not much out there when I google 'rspec
attr_accessor'

The best I've found (not tried) is:
https://gist.github.com/daronco/4133411#file-have_attr_accessor-rb

Or (only does attr_accessor):
http://stackoverflow.com/questions/24434381/ruby-rspec-how-should-i-be-testing-attr-accessor

What's the DRY way to write specs for methods created with
attr_(accessor|writer|reader)?

(Note, this is not rails)

Cheers,
Tom

[Jon Rowe]

Personally, I wouldn’t write specs for that directly, but I might check that attributes are instantiated correctly e.g.:

it “defaults to a good value” do

  expect(test_framework.name).to eq “RSpec"

end

Or that changing a attributes value changes something else

it “changes a persons full name” do

  expect { person.first_name = “Jon” }.to change { person.full_name }.to “Jon Rowe"

end

If you really wanted to check it on it’s own you could just do:

it “has an attribute” do

  expect { person.name = “Jon” }.to change { person.name }.to “Jon"

end

Jon Rowe

---------------------------

ma...@jonrowe.co.uk

jonrowe.co.uk

--

You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.

To post to this group, send email to rails-...@googlegroups.com.

Visit this group at https://groups.google.com/group/rails-oceania.

For more options, visit https://groups.google.com/d/optout.

[Garrow Bedrossian]

Hi Tom,

This sounds a bit like you are "testing the framework". I tend to find tests which assert the framework did its job correctly of low value.

If your public methods, which are part of your classes interface need testing, specify what is interesting about those methods. 

These methods could probably be covered by other explicit  tests, where there is logic to be tested. 

If you have a •lot• of accessor methods which you do want to test, remember that rspec is "just" ruby, and you can generate test cases programmatically. 

Note that you need to put the context inside the each loop in rspec, or your spec contexts get clobbered. 

%w( foo bar baz ).each do |accessor_method|

  context "#{accessor_method} reads and writes" do

...

Cheers

Garrow

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.
To post to this group, send email to rails-...@googlegroups.com.
Visit this group at https://groups.google.com/group/rails-oceania.
For more options, visit https://groups.google.com/d/optout.

--
Garrow Bedrossian
+ 61 401 532 538

[Chris Berkhout]

I wouldn't write specs for that either, but I wanted to mention a more general point...

 

... "testing the framework". I tend to find tests which assert the framework did its job correctly of low value.

It depends on the developers and the framework. Writing a spec of framework/library behaviour can be a useful exercise if there are details you're unfamiliar with. When depending on things working in a certain way that isn't documented elsewhere, I find specs can be a good way to verify and document your assumptions.

I've done it before to assert the behaviour of network IO when not gracefully closed, certain aspects of BigDecimal and PostgreSQL isolation levels. I usually wouldn't object if someone wanted to remove such specs from a project, but if they are done right they probably won't add much of a maintenance overhead.

Cheers,

Chris

[Garrow Bedrossian]

Yep, it's always case by case. I will often use rspec-rails' validate_* assertions, not to test that the framework does what I want, but to document that the class *has* those validations.

--

You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.
To post to this group, send email to rails-...@googlegroups.com.
Visit this group at https://groups.google.com/group/rails-oceania.
For more options, visit https://groups.google.com/d/optout.

[Elle]

I usually use shoulda-matchers assertions for this, mainly for documentation rather than testing the framework.

[Garrow Bedrossian]

Elle, I stand corrected, it is shoulda-matchers I use also. (I had conflated them with rspec-rails in my mind.) 

Thanks!

On Monday, 11 January 2016, Elle <elleme...@gmail.com> wrote:

I usually use shoulda-matchers assertions for this, mainly for documentation rather than testing the framework.

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.
To post to this group, send email to rails-...@googlegroups.com.
Visit this group at https://groups.google.com/group/rails-oceania.
For more options, visit https://groups.google.com/d/optout.