Re: [rspec] Coverage 100%

[Jason Fleetwood-Boldt]

Create some fake data (inputs), call your code, and then assert that the output (results) are what you expect. That’s fundamentally the concept behind all testing. 

I love and use SimpleCOV, a gem which shows you line-by-line what you have written test coverage for (it does not show you that you wrote the correct test, just that the line of code was covered). IMHO, SimpleCov should be a standard part of every Rails’ developer toolkit and is invaluable when you are learning. 

-Jason

On Jun 8, 2015, at 10:43 AM, Krzych0o <kpast...@striketech.pl> wrote:

Hi!

I have no idea how to test bellow code:

process_urls(urls) do |link|
    results[link.url] = link
 end


https_urls = results
        .select { |_url, link| link.youtube? }
        .map { |url, _link| "https://#{url}" }


Could you help me to solve this ?

--
You received this message because you are subscribed to the Google Groups "rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/9766e61d-9b19-437a-8651-7039fbb2b2c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Krzych0o]

I use this tool but i can't solve it

Here is my test code:

context 'my test' do
  let(:url) { Faker::Internet.url }
  let(:response) { [{ name: name, url: url }].to_json }
  let(:urls) { [url] }
  let(:results) do
    Fb::Link.new(
        name: name,
        url: link,
        like_count: 1
    )
  end
  let(:https_urls) { response }
  let(:prev_link) { url }
  before do

    allow(subject).to receive(:process_urls).and_return(response)
  end


  it 'something' do

    expect(subject).to receive(:process_urls) do |link|
      expect(link).to eq [url]
    end
    expect(subject.send(:batch, urls)).to eq []
  end

[Jason Fleetwood-Boldt]

Sounds way overcomplicated for what you are trying to do.

I think you might have fallen into a classic trap of Rspec & TDD in general-- this is one of the reason why I do not support or use Rspec in a declarative style syntax as most of the docs suggest you do.

 Think about this:

allow(subject).to receive(:process_urls).and_return(response)

Basic question: Are you testing the process_urls method itself? What you've done is stubbed it out, which is only appropriate when you're testing  some other code and you don't want to test this code.

If you're testing the process_urls code, then don't stub it out.

I'm afraid the Rspec documentation has led you astray here and significantly confused you.

Wouldn't an approach like this be much simpler:

input = [...,...]

result = my_method(input)

expect(result).toBe (...)

The layers and layers of indirection in this testing style make it nearly impossible to read and I fear you may be stubbing out code that you actually want to be testing.

Don't get me wrong, stubbing is important to do-- but you should only stub out code when it is not in the class you're testing. (OK, very rarely you may be testing a method and want to stub out another method in the same class, but I even think that is an anti-pattern). Working with other objects that another library provides? Sure, stub it out. Working with an API that is bring written by another team? Absolutely, stub that out. Don't stub out the code that's the subject matter of the thing you are actually testing -- this is a snake eating its own tail and when you write tests like that you aren't really testing at all. 

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/5febde95-e0aa-40b4-8e51-65477b881d12%40googlegroups.com.

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

----

Jason Fleetwood-Boldt

te...@datatravels.com

http://www.jasonfleetwoodboldt.com/writing