discourse/spec/components/new_post_result_spec.rb

# frozen_string_literal: true

require 'rails_helper'
require 'new_post_result'

describe NewPostResult do

  it "fails by default" do
    result = NewPostResult.new(:eviltrout)
    expect(result.failed?).to eq(true)
    expect(result.success?).to eq(false)
  end

end
DEV: use #frozen_string_literal: true on all spec This change both speeds up specs (less strings to allocate) and helps catch cases where methods in Discourse are mutating inputs. Overall we will be migrating everything to use #frozen_string_literal: true it will take a while, but this is the first and safest move in this direction 2019-04-30 10:27:42 +10:00			`# frozen_string_literal: true`

Prepare for separation of RSpec helper files Since rspec-rails 3, the default installation creates two helper files: * `spec_helper.rb` * `rails_helper.rb` `spec_helper.rb` is intended as a way of running specs that do not require Rails, whereas `rails_helper.rb` loads Rails (as Discourse's current `spec_helper.rb` does). For more information: https://www.relishapp.com/rspec/rspec-rails/docs/upgrade#default-helper-files In this commit, I've simply replaced all instances of `spec_helper` with `rails_helper`, and renamed the original `spec_helper.rb`. This brings the Discourse project closer to the standard usage of RSpec in a Rails app. At present, every spec relies on loading Rails, but there are likely many that don't need to. In a future pull request, I hope to introduce a separate, minimal `spec_helper.rb` which can be used in tests which don't rely on Rails. 2015-10-11 10:41:23 +01:00			`require 'rails_helper'`
`NewPostManager` determines whether to queue a post or not 2015-03-31 12:58:56 -04:00			`require 'new_post_result'`

			`describe NewPostResult do`

			`it "fails by default" do`
			`result = NewPostResult.new(:eviltrout)`
			`expect(result.failed?).to eq(true)`
			`expect(result.success?).to eq(false)`
			`end`

			`end`