Improve unit test coverage for models #1131
|
+1 on revisiting that decision. It also seems like having that much logic
in some of the controllers might mean there's some too-tightly-coupled
stuff going on.
…
|
| @@ -239,9 +239,8 @@ def update_newsletter_subscription | ||
| end | ||
| end | ||
| - def newsletter_subscribe(testing = false) | ||
| + def newsletter_subscribe(gb = Gibbon::API.new, testing = false) |
Is it better to consider shifting this to an 'action' or similar pattern later?
class NewsletterAction
def initialize(gb = ..., testing = ...)
def subscribe(member)
def unsubscribe(member)
end
Could you use a double in the specification instead of changing the method?
@Br3nda: I changed the method so I could inject a double :-) I looked at using any_instance, but saw it was deprecated; OTOH, I ended up using receive_message_chain, which is also deprecated. Should I just go ahead and use any_instance, or can you suggest a better way?
| @@ -250,9 +249,8 @@ def newsletter_subscribe(testing = false) | ||
| }) | ||
| end | ||
| - def newsletter_unsubscribe(testing = false) | ||
| + def newsletter_unsubscribe(gb = Gibbon::API.new, testing = false) | ||
| return true if (Rails.env.test? && !testing) |
Should we look at VCR or a fake API driver instead of return true at a later point
| @@ -76,7 +76,7 @@ | ||
| Time.stub(now: Time.now) | ||
| end | ||
| - let(:post) { FactoryGirl.create(:post, created_at: 1.day.ago) } | ||
| + let!(:post) { FactoryGirl.create(:post, created_at: 1.day.ago) } |
I'm not always sold on let! sharing state across tests, I keep getting bitten in subtle ways I didn't expect - I tend to prefer a context and before to describe the test setup; then do expectations about the results
|
We seem to have a lot of scope/sql tests, which means we're doing Maybe down the track we can tweak stuff like
into two parts: "Fetch data from store/wherever" and "manipulate data to results we want"; and only really test the 'manipulate' side of things with model specs. Right now that above method could be almost entirely stuffed into the SQL layer as something like:
|
|
Merging this since it has two +1s. This approach to testing the Gibbon-related code isn't ideal, but we can improve it when we add test coverage for the Flickr code, which will have similar issues. |
Adds some unit tests for posts and crops, and does some slight cleanup of the existing tests there. Also adds one feature test for "sign-in using email address rather than username", because that works by implementing a callback for Devise to use, and it didn't seem that unit-testing the callback was very worthwhile: the callback is trivial, the question is whether it matches Devise's expectations.
The two models with big coverage gaps are Member and Photo, because of the code to talk to Gibbon and Flickr. We could (and perhaps should) get those coverage numbers up with some judicious mocking. Edit: I've made a start at this.
The directory with the worst coverage is hands-down
app/controllers, some of whose members have dire coverage. We deprecated controller tests a while back in favour of feature tests; in view of our problems with flaky CI, I think we should revisit that decision.