Adding some polls API endpoints for PR to discourse_api, which work fine. Now I’m trying to understand how to create tests before submitting the PR, e.g.:
require 'spec_helper'
describe DiscourseApi::API::Polls do
subject { DiscourseApi::Client.new("http://localhost:3000", "test_d7fd0429940", "test_user" )}
describe "#polls" do
before do
stub_get("http://localhost:3000/polls/voters.json").to_return(body: fixture("voters.json"), headers: { content_type: "application/json" })
end
it "requests the correct resource" do
subject.voters :post_id => 27885, :poll_name => 'poll'
expect(a_get("http://localhost:3000/polls/voters.json")).to have_been_made
end
end
end
But am getting the error:
Failed to open TCP connection to localhost:3000 (Connection refused - connect(2) for "localhost" port 3000)
# ./lib/discourse_api/client.rb:141:in `rescue in request'
# ./lib/discourse_api/client.rb:132:in `request'
# ./lib/discourse_api/client.rb:85:in `get'
# ./lib/discourse_api/api/polls.rb:22:in `voters'
# ./spec/discourse_api/api/polls_spec.rb:12:in `block (3 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# Errno::ECONNREFUSED:
# Connection refused - connect(2) for "localhost" port 3000
# /Users/kimardenmiller/.rbenv/versions/2.5.3/gemsets/d_api/gems/webmock-2.3.2/lib/webmock/http_lib_adapters/net_http.rb:109:in `request'
All the existing tests pass fine for me, and I’m trying to copy the format of those existing tests, but cannot for the life of me figure out what I’m doing wrong.
Here’s the (new) endpoint being tested:
module DiscourseApi
module API
module Polls
def poll_voters(args)
args = API.params(args) # post_id, poll_name, user, opts = {}
.required(:post_id, :poll_name)
.optional(:opts, :api_username)
response = get("/polls/voters.json", args)
response[:body]
end
end
end
end
Have working tests, though my gut tells me I could use tips on making those urls more elegant.
require 'spec_helper'
describe DiscourseApi::API::Polls do
subject { DiscourseApi::Client.new("http://localhost:3000", "test_d7fd0429940", "test_user" )}
describe "#polls" do
before do
stub_get("http://localhost:3000/polls/voters.json?post_id=27885&poll_name=poll").to_return(body: fixture("polls_voters.json"), headers: { content_type: "application/json" })
end
it "requests the correct resource" do
subject.poll_voters post_id: 27885, poll_name: 'poll'
expect(a_get("http://localhost:3000/polls/voters.json?post_id=27885&poll_name=poll")).to have_been_made
end
it "returns the expected votes" do
voters = subject.poll_voters post_id: 27885, poll_name: 'poll'
expect(voters).to be_a Hash
voters.each { |g| expect(g).to be_an Array }
expect(voters['voters']['e539a9df8700d0d05c69356a07b768cf']).to be_an Array
expect(voters['voters']['e539a9df8700d0d05c69356a07b768cf'][0]['id']).to eq(356)
end
end
end
Glad you got the tests working. They can be tricky sometimes because if the request doesn’t match exactly it will try and create an actual request rather that using the stubbed request.
I think the urls are okay. It would be nice not to use such a high post_id, but I’m not concerned about that. And ALL the tests need to have http://localhost:3000 extracted out into a common variable, but that should probably be done in a separate commit. Whenever you are ready you can go ahead and submit a pr and I can review it.
One thing I did notice though is I that passing in the api_username as a parameter is no longer supported.
This is because the discourse_api gem now only passes in the auth via the headers, and discourse core ignores any auth credentials in the body if the header is already being used for auth.
لنقم بتقسيم طلبات السحب (PRs) من فضلك. أولاً، دعنا نركز على طلب السحب المتعلق بالمواصفات (spec) ولنقم بنقل المتغير المشترك إلى مجلد المواصفات. يجب أن نكون قادرين على إضافته إلى ملف مساعد المواصفات (spec helper file).
نظرًا لأن هذا مخصص للأمثلة فقط، يجب أن يكون أي شيء متعلق بهذا داخل دليل الأمثلة، دون تعديل أي من الوظائف الموجودة داخل دليل lib. حتى ملف config.yml، يجب وضعه داخل دليل الأمثلة. تحميل ملف YAML خفيف الوزن للغاية، ويمكننا إضافته إلى أعلى كل ملف مثال، ولكن من الأفضل على الأرجح إضافته إلى ملف مشترك داخل دليل الأمثلة يمكنه جميع الملفات قراءته منه.
# host مثل localhost:3000 أو discourse.my_domain.com
host: YOUR_HOST_NAME
# مستخدم الـ API (يمكن أن يؤثر على النتائج المسترجعة، فمثلاً طريقة .categories تُرجع فقط الفئات التي يمكن لمستخدم الـ API رؤيتها)
# أنشئ عميلًا جديدًا عند تغيير مستخدم الـ API
api_username: YOUR_API_KEY
# مفتاح الـ API من لوحة تحكم Discourse الإدارية /admin/api/keys
api_key: YOUR_API_KEY
examples/badges.rb
require_relative 'example_helper'
# احصل على الشارات
puts client.badges
أفكار؟ بالتأكيد نحتاج إلى ملف yml الآن، نظرًا لوجود example_helper.rb؟
يبدو الأمر جيدًا. دعنا نحدّث مساعد المثال بقيم افتراضية بحيث يعمل دون الحاجة إلى ملف YAML. ثم قم بتحديث ملف README بإرشادات لنسخ ملف YAML المثال إلى examples/config.yml. وتأكد من إضافة examples/config.yml إلى ملف .gitignore.
هذا أسلوب شائع جدًا بحيث لا يكون من السهل إيداع ملف config.yml يحتوي على بيانات اعتماد الإنتاج. ويمكنك تحرير الملف دون أن يراه Git كتغيير.
أعتقد أن هذا الخطأ مقبول لأن هذا هو كيفية عمل الأمثلة حاليًا، وهذا الأمر موجود في الأمثلة فقط. إذا أردت، الآن أو لاحقًا، يمكننا دائمًا التقاط الاستثناء وتقديم رسالة مفيدة.
قسم الاختبار الحالي لدينا مربك قليلاً بالنسبة لي، حيث يخلط بين المهام المتعلقة بـ discourse_api وبين تثبيت Discourse نفسه. على سبيل المثال: إذا كان لديك خادم تجريبي في السحابة، فلن تحتاج إلى تثبيت Discourse محليًا على الإطلاق. ما رأيك في: