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.
Давайте разделим PR. Сначала сосредоточимся на спецификации и переместим общую переменную в папку spec. Мы должны иметь возможность добавить её в файл helper для spec.
Поскольку это только примеры, всё, что связано с ними, должно находиться внутри каталога examples, и мы не должны изменять существующую функциональность в каталоге lib. Даже файл config.yml следует разместить внутри каталога examples. Загрузка YAML-файла довольно легковесна, и мы можем добавлять её в начало каждого файла примера, но, вероятно, лучше добавить её в общий файл внутри каталога examples, из которого все они смогут читать данные.
# host, например localhost:3000 или discourse.my_domain.com
host: ВАШЕ_ИМЯ_ХОСТА
# пользователь API (может влиять на возвращаемые результаты, например, метод .categories возвращает только те категории, которые видит api_username)
# создавайте нового клиента при смене пользователя API
api_username: ВАШ_API_КЛЮЧ
# ключ API из панели администратора Discourse /admin/api/keys
api_key: ВАШ_API_КЛЮЧ
examples/badges.rb
require_relative 'example_helper'
# получить значки
puts client.badges
Что думаете? Нам действительно нужен файл yml сейчас, учитывая example_helper.rb?
Выглядит хорошо. Давайте обновим пример вспомогательного файла, добавив значения по умолчанию, чтобы он работал без файла yml. Затем обновите файл README инструкциями по копированию примера файла yml в examples/config.yml. И обязательно добавьте examples/config.yml в .gitignore.
Это довольно стандартная практика, чтобы избежать случайного коммита файла config.yml с учётными данными для продакшена. Кроме того, вы сможете редактировать этот файл, и git не будет считать это изменением.
Я думаю, что эта ошибка допустима, поскольку именно так сейчас работают примеры, да и в любом случае это касается только примеров. Если захотите, сейчас или позже, мы всегда можем перехватить исключение и вывести понятное сообщение.
Мне кажется, что наш текущий раздел «Тестирование» немного запутанный, поскольку он смешивает задачи, связанные с discourse_api, с установкой самого Discourse. Например, если у вас есть тестовый сервер в облаке, вам вовсе не нужно устанавливать Discourse локально. Как вы относитесь к следующему варианту:
Примеры и тестирование
Чтобы попробовать примеры или запустить тесты, вам потребуется работающий экземпляр Discourse, установленный либо локально, либо в облаке.
Примеры
Чтобы запустить примеры из папки /examples:
Укажите настройки окружения, создав копию файла config-example.yml и назвав её config.yml, заполнив её параметрами вашего окружения.
В нужном файле примера закомментируйте все примеры, кроме тех, которые вы хотите запустить.
Отредактируйте файл примера, добавив необходимые параметры, например username.
При запуске файла данные будут считываться из config.yml для вызова соответствующего метода клиента (например, client.badges) в вашем экземпляре Discourse.
Тестирование
Чтобы запустить тесты discourse_api из папки spec:
Установите bundler в директории discourse_api, выполнив команду gem install bundler.
Находясь в директории discourse_api, выполните: bundle exec rspec spec/.