[rspec] RSpec 3.8 has been released

[Myron Marston]

For more details, check out the blog post:

http://rspec.info/blog/2018/08/rspec-3-8-has-been-released/

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/18af74cb-0c5c-4ff6-8979-bd7da693f4d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: The use of doubles or from rspec-mocks outside of the per-test lifecycle is not supported

[Myron Marston]

That works, or you can use `RSpec::Mocks.with_temporary_scope { ... }` to
create a scope for use within your `before(:all)` hook.  See this for more
information:

https://relishapp.com/rspec/rspec-mocks/v/3-7/docs/basics/scope#use-%60with-temporary-scope%60-to-create-and-use-a-double-in-a-%60before(:context)%60-hook

On Tue, Jul 3, 2018 at 7:00 AM belgoros  wrote:

> I figured out after reading the docs
> 
> :
>
> Mocks are only supported in before(:example).
>
> So the only way to get it working is to use
> before(:example)
>
>   hook.
>
> Hope this helps.
>
> On Tuesday, 3 July 2018 15:53:41 UTC+2, belgoros wrote:
>>
>> If is not supported, what is the right way to mock an object once before
>> all the examples ?
>>
>>
>> Here is what I tried to do and failed:
>>
>> describe '#build_working_hour' do
>>
>>   context "for open status" do
>>   before(:all) do
>> @schedule = double(MystoreMigration::StoreSchedule, am_start_time
>> : 900, pm_end_time: 2030)
>> allow(@schedule).to receive(:has_divided_hours?).and_return(false
>> )
>> allow(@schedule).to receive(:closed?).and_return(false)
>> @working_hour = store_migrator.build_working_hour(schedule)
>>   end
>>
>>
>>   it 'should init working hour with open status' do
>> expect(@working_hour.open?).to be_truthy
>>   end
>>
>>
>>   it 'should init working hour with open status times' do
>> expect(@working_hour.opens).to eq(32_400_000)
>> expect(@working_hour.closes).to eq(73_800_000)
>> expect(@working_hour.divided_opens).to be nil
>> expect(@working_hour.divided_closes).to be nil
>>   end
>> end
>> end
>>
>>
>> What is wrong with the above approach ? I'd like to 1) check a status, 2)
>> the assigned values. Thank you!
>>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/88c810fd-bc60-46ba-8ff2-22ef1e16e08a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtz%3DJZBBsc_kxu_Yg64N1bJVLxp2XuQB1AU3HVrsDkxRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Testing return value after raising an exception

[Myron Marston]

Hi Carlos,

It’s not clear to me what you’re trying to accomplish with that example.
Meep#call has a rescue clause but the code being rescued involves no method
calls ("no error" is not a method call) and, barring something truly
bizarre like a busted ruby installation, cannot raise any sort of
exception. As there’s no possibility of an ArgumentError being raised,
there’s no point in rescuing it (or in trying to write a test to cover the
possibility of an exception being raised).

In addition, allow_any_instance_of(Meep).to
receive(:call).and_raise(ArgumentError) completely replaces your existing
implementation of Meep#call including the rescue ArgumentError.

I’m not sure what to suggest since your example doesn’t make sense to me.

Myron
​

On Mon, Jun 4, 2018 at 4:16 PM, Carlos Rodriguez  wrote:

> Hello folks,
>
> I'm trying to test the return value of a method after an exception is
> called and I'm unsure of how to actually test this. I basically want to
> throw away the exception to see the return value. See the super contrived
> example below:
>
> class Foo
>   def call
> Bar.new.call
>   end
> end
>
> class Bar
>   def call
> Meep.new.call
>   end
> end
>
> class Meep
>   def call
> "no error"
>   rescue ArgumentError
> "error"
>   end
> end
>
> allow_any_instance_of(Meep).to receive(:call).and_raise(ArgumentError)
> expect(Foo.new.call).to eq "error"
>
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/9a05e52f-21c5-49bf-808b-e826261f9936%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmuwGYSNOU8uQsVLT9waGCkcQK8mZ7Nb_RPzv-iihKLTSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Raising a mocked exception

[Myron Marston]

In general, I recommend that you don't use test doubles in place of value
objects, and generally exception types are value objects.  (That is, they
carry data, but don't have any meaningful behavior and certainly shouldn't
perform any I/O).  Given that, I don't understand why you'd want to use a
test double in place of an exception.

The fact that you find yourself wanting to is probably communicating
something about your design, and you may want to take a step back to think
through why you're trying to use a double in place of an exception.
There's likely an alternate design that will work better.

HTH,
Myron

On Wed, Apr 11, 2018 at 1:34 PM, David Shockley 
wrote:

> Cool. That makes sense. My current work around is to use:
>
> allow_any_instance_of(Exception).to receive(:my_custom_method_ive_
> added_to_exception).and_raise
>
> Is there a better solution? Do you think it's possible to write an
> exception_double and exception_spy methods that build subclasses of
> Exception that support the double/spy methods directly, or is that
> unfeasible / a bad idea?
>
>
>
> On 11 April 2018 at 13:01, Myron Marston  wrote:
>
>> Ruby requires that any object passed to raise must be an exception class
>> or object:
>>
>> 2.4.3 :001 > raise Object.newTypeError: exception class/object expected
>> from (irb):1:in `raise'
>> from (irb):1
>> from /Users/myron/.rvm/rubies/ruby-2.4.3/bin/irb:11:in `'
>>
>> As such, there’s no way to RSpec to be able to raise an arbitrary object.
>>
>> Myron
>> ​
>>
>> On Wed, Apr 11, 2018 at 12:43 PM, Asher Shockley <
>> daemon.shock...@gmail.com> wrote:
>>
>>> Is it possible to have a mocked method raise a mocked object instead of
>>> a real instance of Exception?
>>>
>>> https://gist.github.com/david-shockley-beeline/008ea9122e62b
>>> 051b3614d07a36fae23
>>>
>>> Thanks
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To post to this group, send email to rspec@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/rspec/76d123cf-1fe0-4d88-b0fd-47a856253c22%40googlegroups.com
>>> <https://groups.google.com/d/msgid/rspec/76d123cf-1fe0-4d88-b0fd-47a856253c22%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to rspec@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/rspec/CADUxQmv5n_2fYTHRtQpy9%3Dxeom1Cj8Mb4kUS7kQsx-a%3DM
>> 01hEA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/rspec/CADUxQmv5n_2fYTHRtQpy9%3Dxeom1Cj8Mb4kUS7kQsx-a%3DM01hEA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/CACp6SzUuvsS23SRw%2Bgwws3jiTCv-NazBOa3NJGyKBvNt8FV1_g%40mail.
> gmail.com
> <https://groups.google.com/d/msgid/rspec/CACp6SzUuvsS23SRw%2Bgwws3jiTCv-NazBOa3NJGyKBvNt8FV1_g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtYGyYV8CM6Vki0roDdUYkHK38H2EjkN%3DJ0kkbdjAmrnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Raising a mocked exception

[Myron Marston]

Ruby requires that any object passed to raise must be an exception class or
object:

2.4.3 :001 > raise Object.newTypeError: exception class/object expected
from (irb):1:in `raise'
from (irb):1
from /Users/myron/.rvm/rubies/ruby-2.4.3/bin/irb:11:in `'

As such, there’s no way to RSpec to be able to raise an arbitrary object.

Myron
​

On Wed, Apr 11, 2018 at 12:43 PM, Asher Shockley 
wrote:

> Is it possible to have a mocked method raise a mocked object instead of a
> real instance of Exception?
>
> https://gist.github.com/david-shockley-beeline/
> 008ea9122e62b051b3614d07a36fae23
>
> Thanks
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/76d123cf-1fe0-4d88-b0fd-47a856253c22%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmv5n_2fYTHRtQpy9%3Dxeom1Cj8Mb4kUS7kQsx-a%3DM01hEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Waiting docker container to continue tests

[Myron Marston]

RSpec doesn’t have any built-in features for what you’re asking for, but
it’s easy enough to write it yourself:

require 'timeout'
module WaitHelpers
  def wait_until(timeout)
timeout_time = Time.now + timeout
loop do
  sleep 0.1
  return if yield
  raise Timeout::Error if Time.now > timeout_time
end
  end

  def wait_until_port_available(container)
wait_until(10) do
  container.port.available? # or whatever the logic to check port
availability is
end
  endend
RSpec.configure do |rspec|
  rspec.include WaitHelpersend
RSpec.describe "A docker container" do
  before do
@container = Docker::Container.create
@container.start
wait_until_port_available(@container)
  endend

​


HTH,
Myron

On Fri, Apr 6, 2018 at 5:44 AM, Samuel Mutel  wrote:

> Hello,
>
> I am currently using rspec and docker api to test docker container
> (@container = Docker::Container.create & @container.start).
> I would like to know if it is possible to wait a condition (port available
> for example) to continue the test suite?
> I saw this module rspec-wait ...
>
> Thanks.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/1ff39192-ef6a-4dd1-830c-c120d61faafd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmufRPiOaG3shc00BePoC29q5iJ45pkDvP6ypbgKj%3DcFbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] RSpec error: "MissingSpecVersionError"

[Myron Marston]

Hi Bijaya,

I'm sorry to hear you're having problems installing RSpec on Windows 7.
>From your description, it sounds like the problem you're having is with
your ruby and gem installation tools, and not a problem with RSpec itself.
Maybe there's a windows user on this group who can help but most people
here (including myself) use POSIX systems.  You'll probably have better
luck asking for help from a ruby windows users group.

Good luck!
Myron

On Tue, Mar 6, 2018 at 10:45 AM, Bijaya Manandhar <
manandhar.bij...@gmail.com> wrote:

> I have Ruby version 2.4.3 installed from RubyInstaller. After that I used
> msys64 to install RSpec that gave me RSpec 3.7.1 straight. Now my system
> does not want to talk between Ruby and RSpec. It pops up with
> "MissingSpecVersionError". I tried all I know to match the versions but did
> not find bundle that matches.
>
> I work on Windows 7.
>
> Your help is highly appreciated.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/0becd1d8-8410-4b65-afe0-6d86888a0ef6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtqnhjrd%2BfLQBvL-XtECbjVq%3Db0B_-8JEFH4McfuiqGEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Separate html report for each directory passed to rspec command

[Myron Marston]

The simplest way to get what you want is just to run rspec twice:

$ rspec dir1 --format html --out dir1.html && rspec dir2 --format html
--out dir2.html

You could also look into creating a custom formatter
.

HTH,
Myron
​



On Tue, Mar 6, 2018 at 3:08 AM, SACHIN V  wrote:

> Hi,
>
> I would like to run my tests in the following manner:
>
> rspec  
>
> And I require html results of tests in dir1 and dir2 to be displayed in
> separate reports? Can someone please tell me if that's possible?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/f5545bdc-76ba-4a56-8bf8-3e4d8fbc45c2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmu2aFbNqbaW-anJiJLq4iKE-GuYw-Yf42%3DDat9z_MGLeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Hint needed to migrate rspec code

[Myron Marston]

Please follow our RSpec 2 -> 3 upgrade guide:

http://rspec.info/upgrading-from-rspec-2/

If that doesn't work, let us know.

Thanks,
Myron



On Wed, Feb 28, 2018 at 1:09 PM, hartmut bischoff 
wrote:

> Hi everyone,
>
> I am updating ib-ruby (https://github.com/ib-ruby/ib-ruby)
> Some Code is written for Rspec 2 (I think), and  does not run anymore.
>
> How to fix this:
>
>> describe IB::Bar,
>
>  :props =>
>>  {:open => 1.31,
>>   :high => 1.35,
>>   :trades => 50,
>>   :time => "20120312  15:41:09",
>>  },
>>
>>  :human =>
>>  "> trades 50 vol 2 gaps true>",
>>
>>  :errors =>
>>  {:close => ["is not a number"],
>>   :volume => ["is not a number"]},
>>
>>  :assigns =>
>>  {:has_gaps => {[1, true] => true, [0, false] => false},
>>
>>   [:open, :high, :low, :close, :volume] =>
>>   {[:foo, 'BAR', nil] => /is not a number/}
>>  } do # AKA IB::Bar
>>
>>   it_behaves_like 'Model with invalid defaults'
>>   it_behaves_like 'Self-equal Model'
>> end
>>
>
> It gives a bunch of errors, like
>
>   6) IB::Bar behaves like Model with invalid defaults instantiation with
>> properties behaves like Model instantiated with properties auto-assigns all
>> properties given to initializer
>>  Failure/Error:
>>props.each do |name, value|
>>  # p name, subject.send(name), value
>>  subject.send(name).should == value
>>end
>>
>>`example` is not available from within an example (e.g. an `it`
>> block) or from constructs that run in the scope of an example (e.g.
>> `before`, `let`, etc). It is only available on an example group (e.g. a
>> `describe` or `context` block).
>>  Shared Example Group: "Model instantiated with properties" called
>> from ./spec/model_helper.rb:179
>>  Shared Example Group: "Model with invalid defaults" called from
>> ./spec/models/ib/bar_spec.rb:33
>>  # (eval):2:in `rescue in props'
>>  # (eval):2:in `props'
>>  # ./spec/model_helper.rb:220:in `block (2 levels) in > (required)>'
>>  # --
>>  # --- Caused by: ---
>>  #   `metadata` is not available from within an example (e.g. an `it`
>> block) or from constructs that run in the scope of an example (e.g.
>> `before`, `let`, etc). It is only available on an example group (e.g. a
>> `describe` or `context` block).
>>  #   (eval):2:in `props'
>>
>
> Is there an easy way, to make the tests valid again  or do I have to write
> it new from stretch?
>
> Thanks in advance
>
> hartmut
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/da2fafd4-6f1a-46de-8f0f-01ba89cb9f74%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmscOCassTkx7Rk2WK5UJNh%2BbQZBFVm-rXxmVR5D7z5bjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] How to structure my testing with RSpec

[Myron Marston]

Hi Jeff,

So my only chance to test them both is either run them dependently from one
> another or to create data specific for each test (which I cannot always
> afford, which is why I do more of what I call integration where I make
> weird scenarios accumulating this sort of dependency tests).


Having each test be independent is really important.  The fact that it's
too expensive to create data specific for each tests suggests that your
testing strategy is poorly suited to provide the benefits you're looking.
End-to-end tests like the ones you're working on are generally the most
expensive tests on every project and I favor having very few of them,
pushing most tests down to the unit test level.  That generally requires
that the tests are written in conjunction with the production code in order
to influence its design, so that may not be feasible in your case.

I don't think we're going to be able to give you satisfactory answers (as
we'd have to dig into your project in more detail to do that, and I don't
have the time for that).  I think that some books that help you think about
the costs and benefits of different approaches to testing could help you,
though.  If you're looking for an RSpec-specific book, I'd recommend *Effective
Testing with RSpec 3
, *which
was published about 6 months ago.

Good luck!
Myron



On Tue, Feb 20, 2018 at 2:09 PM, Jeff Fagot  wrote:

> Hello,
>
> I am posting here because I am using RSpec, even if this question is
> probably broader than the framework I am using...
>
> *A little background*:
> Basically I am a manual tester of web applications who is trying to make
> his way toward automation using RSpec with WATIR gem.
> I feel like BDD is the natural path coming from manual testing. I must
> confess that I had initially started using Cucumber but after being advised
> to avoid that "overhead" and "simply" use RSpec (which is compatible with
> Cucumber), so I did but not without questioning myself...
> Also I am barely starting with Page-Object and still have nothing to
> manage my data... (I have only wrote a couple of simple scenarios so far)
>
> *Here is my problem*:
> I usually tend to create integration/End-to-End tests (Always dependent on
> data state).
> So when I go to write my _specs, they always starts by a specific state,
> then I try to DRY them up as follow:
>  1. Create sort of "Unit Test" Scenarios
>  2. Make my Unitary Scenarios functions of variable, so I can re-use the
> same for all(as much as possible) cases
>
> Now I am wondering what to do? or maybe how to structure myself?
>
> *QUESTIONS:*
>  1. Should I turn what I call Unitary Scenario/Test into actual
> Function/Module? To then be used into true integration test specifications?
>  OR
>  2. Should I have Unit Tests and Integration Tests _specs either into
> different files or "tagged"
>  3. Maybe a mix of both?
>
>  How to mediate to 'data state' related issues??
> For example, if I am writing 2 tests : 1 for ADD, 1 For DELETE an element.
> Each test needs to be in the opposite state of the other. So my only chance
> to test them both is either run them dependently from one another or to
> create data specific for each test (which I cannot always afford, which is
> why I do more of what I call integration where I make weird scenarios
> accumulating this sort of dependency tests).
>
> I would appreciate any insights. Also if someone could share some project
> examples that would enlighten me, it would be much appreciated.
>
> Thanks for sharing your experience!
> Jeff
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/cc503083-5058-4287-916a-0d39659f05ae%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvw0FwnkArDeS4iHy%2BX-RQ8svxaRmwCiZwab5%3DR_oExHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Stubbing class inside class method

[Myron Marston]

Hi Paulo,

I can't reproduce your issue.  I ran your code (see this gist
 for
the code I I'm running) and it passes as I would expect.  If you want
someone to look more into this, please provide:

   - An explanation of what isn't working.  "It does not work" is hard to
   interpret.  Maybe it's just a misunderstanding.  Tell us what behavior you
   expect, and what behavior you are seeing, and if there's an exception,
   please provide the stacktrace.
   - Some example code we can download and run to reproduce the issue.  A
   gist like I provided is fine.

Thanks,
Myron

On Thu, Feb 15, 2018 at 12:23 PM, Paulo Fabiano Langer <
paulofabi...@gmail.com> wrote:

> Hi, guys!
>
> I'm struggling with a problem.
>
> Class X
>def y
>   YAML.load_file(...)
>end
> end
>
> In my spec I have
>
> allow(YAML).to receive(:load_file).and_return(...)
> expect(obj.y).to eq ...
>
> And it works!
>
> But, if I change the method to
>
> def self.y
>...
> end
>
> and the expect to:
>
> expect(X.y)...
>
>
> It does not work :(
>
> How can I make this stub and make it work with my class method?
>
> Thanks,
> Paulo
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/46940dac-9fcc-4b6a-a6f2-7cfbbbe6e267%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmuU%2BF8HYsHQ-5h19BRYu9AaKxO%3DFL7mP8rDUVEXAk5pqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] How to instantiate my browser? I can make it work but do not understand why

[Myron Marston]

If you want all examples in a particular context to share an object, the
easiest way is to use before(:context) to initialize it and store it in an
instance variable, and then use that instance variable from your examples.
Here’s an example:

context "my context" doi
  before(:context) { @browser = Watir::Browser.new :firefox }

  it "uses the browser" do
@browser.do_something
  end

  it "uses the browser for something else" do
@browser.do_something_else
  endend

HTH,
Myron
​


On Wed, Jan 17, 2018 at 9:32 AM, Jeff Fagot  wrote:

>
> Thanks Jon for your time and answer.
> Unfortunately, I have to say I am still confused. Moreover (maybe I am
> wrong but) I have never seen anyone doing as you are suggesting and I do
> not want a specific solution but rather a common/best practice solution.
>
> So let me exposed you more to what I am trying to accomplish that would
> probably give you more insights about the "structure I am trying to
> accomplish" (knowing that there are many things I have to improve).
>
> I am thinking of having a _spec file to test all my reports. I am aware
> that I will mostly have to refactor afterwards but for the time being I
> would have within that same _spec file 2 suites defined by their 'context'
> : one for the Type1 and another for the Type2.
> Each 'context' block would have 'its own set of tests defined as
> 'describe' blocks.
> Each 'context' could be run independently from one another and therefore
> have its own browser instance, while within a specific 'context', I would
> want to always refer to the same instance browser to play my test (I would
> log onto the same site with same user once per context).
>
>
> ###  FILE_SPEC.RB ###
> context 'Testing reports of Type = 2' do
>
>   describe 'Given I am logging into QC as a ValidUser' do
> .
> it 'The ValidUser is taken to the Dashboard page' do
>   expect...
> end
>
>   end
>
>   describe 'When I access report_type1 from search' do
> ...
> it 'It opens the report_type1' do
>   expect...
> end
>   end
>
>   describe 'When I filter the report_type1' do
> ...
> it 'Displays the proper page of results' do
>   expect...
> end
>   end
>
> end
>
> context ''Testing reports of Type = 1' do
>   very similar things as above
> end
> 
>
> Any help would be much appreciated.
> Thanks
>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/d3279bff-ed2c-4983-b6a6-cf7c36df7c04%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtFPM3LwquDVPUiMKthx1q1y0%2BAcdXx08_yNakrAGZsGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Custom reporter for passed examples showing all expects

[Myron Marston]

Glad to hear you figured out a solution!

On Thu, Jan 11, 2018 at 8:24 AM, Attila Strba 
wrote:

> Thank you Myron, that is exactly what I needed. Here is my current
> solution documented on StackOverflow: https://stackoverflow.com/questions/
> 48116106/custom-rspec-formatter-to-display-passed-
> test-and-result-of-except/48211635#48211635
>
> On Friday, January 5, 2018 at 5:23:14 PM UTC+1, Myron Marston wrote:
>>
>> Is there a possibility to create a reporter where we get also more
>> information about passed test? What I want is to show which except’s has
>> been executed with which results.
>>
>> You could do that. Create a custom formatter that tracks the information
>> you want and reports it however you want (e.g. to stdout or CouchDB or
>> whatever). Our docs show how to define one
>> <https://relishapp.com/rspec/rspec-core/v/3-7/docs/formatters/custom-formatters>
>> and list all the events you can subscribe to
>> <http://rspec.info/documentation/3.7/rspec-core/RSpec/Core/Formatters/Protocol.html>.
>> It sounds like you want this formatter to be in addition to a normal one
>> (rather than replacing it), so be sure to call config.add_formatter
>> twice — once with your normal output formatter, and once with your custom
>> one.
>>
>> Note that there are no events for each individual expectation. You’ll
>> have to extend RSpec a bit to do that. It’s not too bad, though:
>>
>> module ExtendExpect
>>   def expect(*args, &block)
>> # put whatever custom logic around `expect` you want.  e.g. you could 
>> notify your custom formatter from here
>> super
>>   endend
>> RSpec.configure do |c|
>>   c.include ExtendExpectend
>>
>> HTH,
>> Myron
>> ​
>>
>>
>> On Fri, Jan 5, 2018 at 5:24 AM, Attila Strba 
>> wrote:
>>
>>> Hi Guys,
>>> we are trying to use RSpec for our Integration and System testing. Just
>>> a short overview of our test framework to give some background regarding my
>>> question. We have a various Hardware hooked up to Jenkins clients which we
>>> control over Ruby and control the test execution/test logic currently in
>>> Minitest. The results of the test execution  are beeing pushed to a
>>> CouchDB. We want to move away from Minitest due to it's limitation for this
>>> use case like: no support for test suites, dependent tests, random
>>> execution order etc.  Rspec seems to have all the features we need. There
>>> is one point missing though, and that is my question:
>>>
>>> Is there a possibility to create a reporter where we get also more
>>> information about passed test? What I want is to show which except's has
>>> been executed with which results.
>>>
>>> Thank you in advance for any help.
>>> greetings
>>> Attila
>>>
>>> --
>>> 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/ms
>>> gid/rspec/39fc23b5-b721-478c-9ef8-df60d1c89297%40googlegroups.com
>>> <https://groups.google.com/d/msgid/rspec/39fc23b5-b721-478c-9ef8-df60d1c89297%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/92844eb1-c636-4dd0-8edd-374b9d64edd5%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/92844eb1-c636-4dd0-8edd-374b9d64edd5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsYAQMbdaGyo1umzX2%3DumrHOHJbAqCUBLSym-HoUKD0Lw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Error messages at the bottom or at the top of the page, not handy with very long code

[Myron Marston]

It's not quite clear to me what change you are asking for.  Could you
provide an example of the output you'd like to see?

Regardless, a custom formatter is probably going to be the best way to get
the output you want.  You can customize the output in whatever manner you
like with a custom formatter.

HTH,
Myron

On Sun, Jan 7, 2018 at 11:16 PM, philippe.perret via rspec <
rspec@googlegroups.com> wrote:

> Hi everyone,
>
> (Xavier Shay suggested me to post my question here)
>
> Is there a way to avoid the annoying thing below in rspec feedback when
> the page code is very long?
>
> One time (bad content error) :
>
> Failure/Error: expect(page)...
>
>
>"Mauvais titre" expected within "h2[id='main_titre']" in following
> template:
>
>
> [...
>   a
> very
>   very
>   very
>   long page code (two list, three iframes, etc.)
> ...]
>
>
>
> (the error message is on the top)
>
> Another time (tag missing error):
>
>  Failure/Error: expect(page).send(meth, have_tag(tag, attrs))
>
>
>expected following:
>
> [...
>   a
> very
>   very
>   very
>   long page code (two list, three iframes, etc.)
> ...]
>
>to have at least 1 element matching "h2[id='main_titre']", found 0.
>  # ./spec/..'
>
>
>
> (the error message is on the bottom)
>
> Couldn't it be nice if error message stands both at the top and at the
> bottom (or only at the top or at the bottom)?
>
> By the way, thanks to you and the rspec's team for this wonderful tool!
>
> Cheers,
>
> Philippe (from France)
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/b767c645-a44a-4869-8c76-6c03c5011b49%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmugOqBFQPK%2BzhxhuHyqiJEoArYEQNPJyfsGQ8HJTKTdaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Custom reporter for passed examples showing all expects

[Myron Marston]

Is there a possibility to create a reporter where we get also more
information about passed test? What I want is to show which except’s has
been executed with which results.

You could do that. Create a custom formatter that tracks the information
you want and reports it however you want (e.g. to stdout or CouchDB or
whatever). Our docs show how to define one

and list all the events you can subscribe to
.
It sounds like you want this formatter to be in addition to a normal one
(rather than replacing it), so be sure to call config.add_formatter twice —
once with your normal output formatter, and once with your custom one.

Note that there are no events for each individual expectation. You’ll have
to extend RSpec a bit to do that. It’s not too bad, though:

module ExtendExpect
  def expect(*args, &block)
# put whatever custom logic around `expect` you want.  e.g. you
could notify your custom formatter from here
super
  endend
RSpec.configure do |c|
  c.include ExtendExpectend

HTH,
Myron
​


On Fri, Jan 5, 2018 at 5:24 AM, Attila Strba 
wrote:

> Hi Guys,
> we are trying to use RSpec for our Integration and System testing. Just a
> short overview of our test framework to give some background regarding my
> question. We have a various Hardware hooked up to Jenkins clients which we
> control over Ruby and control the test execution/test logic currently in
> Minitest. The results of the test execution  are beeing pushed to a
> CouchDB. We want to move away from Minitest due to it's limitation for this
> use case like: no support for test suites, dependent tests, random
> execution order etc.  Rspec seems to have all the features we need. There
> is one point missing though, and that is my question:
>
> Is there a possibility to create a reporter where we get also more
> information about passed test? What I want is to show which except's has
> been executed with which results.
>
> Thank you in advance for any help.
> greetings
> Attila
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/39fc23b5-b721-478c-9ef8-df60d1c89297%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvwspC1PH3MzhyQpZyseWng%3Dw3i9rOedTt2HzPkByU%3DKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] How to get the number of tests excluded by `c.filter_run_excluding`?

[Myron Marston]

Can a before hook ever access the metadata of an example (before(:each)?)

A before(:each)/before(:example) hook can access the metadata of the
example, but a before(:all)/before(:context) hook cannot, because in the
latter case, there is no specific example the hook is running as a part of.
It’s another reason to generally avoid :all/:context hooks.

To access the metadata from a hook, you just receive an example argument,
which has a metadata method:

before(:example) do |example|
  pp example.metadataend

HTH,
Myron
​

On Wed, Dec 20, 2017 at 11:15 AM, Jan P.  wrote:

> Thanks for the explanation, now it makes sense what was happening.
>
> I applied that to our project and it is working as expected.
> Thank you so much for your help.
>
>
> Can a `before` hook ever access the metadata of an example
> (`before(:each)`?), or does this only get set after `before` is already
> finished executing?
> I am lucky to not have a test file right now where I have to differentiate
> between tests with a `before` that should run and tests that shold not -
> but I am sure this will happen sooner or later :/
>
> Jan
>
>
>
> Am Mittwoch, 20. Dezember 2017 17:30:11 UTC+1 schrieb Myron Marston:
>>
>> The problem is that you have only set :requires_xcodebuild on the
>> individual examples, and not on the example group as a whole. So when the
>> example group is defined, there is no :requires_xcodebuild metadata, and
>> the define_derived_metadata block does not get invoked to set :skip.
>> Then when you call before, metadata[:skip] returns false, so it proceeds
>> to define the hook normally.
>>
>> RSpec examples inherit metadata from their parent example group (and
>> enclosing example groups inherit from their parent group), so my suggestion
>> is to remove :requires_xcodebuild from the individual examples in that
>> file, and set it on the example group instead. That’ll both fix the issue
>> and ensure that every example automatically has that metadata.
>>
>> Myron
>> ​
>>
>> On Wed, Dec 20, 2017 at 6:34 AM, Jan P.  wrote:
>>
>>> That sounds perfect for my use case. As I introduced `:skip` into the
>>> codebase, I would be pretty comfortable with adding this as well (and
>>> confine it to non-macOS platforms to limit exposure).
>>>
>>> But I can't get it to work. The `before` just runs anyway:
>>>
>>> https://circleci.com/gh/fastlane/fastlane/12612
>>> https://github.com/fastlane/fastlane/blob/a103c655c4162723b9
>>> 6cae8f4a8b1258a1419321/spec_helper.rb#L90-L98
>>> (Tried integrating it into my existing RSpec.configure block as well:
>>> https://github.com/fastlane/fastlane/pull/11284/commits/1815
>>> b4bca04f58ec84fd365097f61b8dd4e68b89#diff-82c4f19cbedb2b12a4
>>> 1b04cdaa3cR87)
>>>
>>> What am I missing?
>>>
>>> Jan
>>>
>>>
>>> Am Mittwoch, 20. Dezember 2017 09:04:32 UTC+1 schrieb Myron Marston:
>>>>
>>>> There is a way you can simplify this further:
>>>>
>>>> module HookOverrides
>>>>   def before(*args)
>>>> super unless metadata[:skip]
>>>>   endend
>>>> RSpec.configure do |c|
>>>>   c.extend HookOverridesend
>>>>
>>>> This overrides before so that it’s a no-op if :skip metadata is set on
>>>> the example group. With that in place, you don’t need to call skip
>>>> from your before(:all) hooks. But bear in mind that if you ever set
>>>> :skip on an example group (to set a default for the group) and then
>>>> set skip: false for a specific example in the group…this override will
>>>> cause the before hook to be skipped even though you’d probably expect
>>>> it in that case. (Which is why we can’t apply this as a generic patch to
>>>> RSpec itself).
>>>>
>>>> HTH,
>>>> Myron
>>>> ​
>>>>
>>>> On Tue, Dec 19, 2017 at 5:45 PM, Jan P.  wrote:
>>>>
>>>>> Thanks Myron, that worked!
>>>>>
>>>>> > 4704 examples, 0 failures, 175 pending
>>>>>
>>>>> With code:
>>>>>
>>>>> before(:all) do
>>>>>   skip "Requires `xcodebuild` to be installed which is not possible 
>>>>> on this platform" unless FastlaneCore::Helper.is_mac?
>>>>>
>>>>> As you can see right now I duplicate the reason text, and use the
>>>>> condition that also triggers `skip`/metadata block:
>>>>> https

Re: [rspec] How to get the number of tests excluded by `c.filter_run_excluding`?

[Myron Marston]

The problem is that you have only set :requires_xcodebuild on the
individual examples, and not on the example group as a whole. So when the
example group is defined, there is no :requires_xcodebuild metadata, and
the define_derived_metadata block does not get invoked to set :skip. Then
when you call before, metadata[:skip] returns false, so it proceeds to
define the hook normally.

RSpec examples inherit metadata from their parent example group (and
enclosing example groups inherit from their parent group), so my suggestion
is to remove :requires_xcodebuild from the individual examples in that
file, and set it on the example group instead. That’ll both fix the issue
and ensure that every example automatically has that metadata.

Myron
​

On Wed, Dec 20, 2017 at 6:34 AM, Jan P.  wrote:

> That sounds perfect for my use case. As I introduced `:skip` into the
> codebase, I would be pretty comfortable with adding this as well (and
> confine it to non-macOS platforms to limit exposure).
>
> But I can't get it to work. The `before` just runs anyway:
>
> https://circleci.com/gh/fastlane/fastlane/12612
> https://github.com/fastlane/fastlane/blob/a103c655c4162723b96cae8f4a8b12
> 58a1419321/spec_helper.rb#L90-L98
> (Tried integrating it into my existing RSpec.configure block as well:
> https://github.com/fastlane/fastlane/pull/11284/commits/
> 1815b4bca04f58ec84fd365097f61b8dd4e68b89#diff-
> 82c4f19cbedb2b12a41b04cdaa3cR87)
>
> What am I missing?
>
> Jan
>
>
> Am Mittwoch, 20. Dezember 2017 09:04:32 UTC+1 schrieb Myron Marston:
>>
>> There is a way you can simplify this further:
>>
>> module HookOverrides
>>   def before(*args)
>> super unless metadata[:skip]
>>   endend
>> RSpec.configure do |c|
>>   c.extend HookOverridesend
>>
>> This overrides before so that it’s a no-op if :skip metadata is set on
>> the example group. With that in place, you don’t need to call skip from
>> your before(:all) hooks. But bear in mind that if you ever set :skip on
>> an example group (to set a default for the group) and then set skip:
>> false for a specific example in the group…this override will cause the
>> before hook to be skipped even though you’d probably expect it in that
>> case. (Which is why we can’t apply this as a generic patch to RSpec itself).
>>
>> HTH,
>> Myron
>> ​
>>
>> On Tue, Dec 19, 2017 at 5:45 PM, Jan P.  wrote:
>>
>>> Thanks Myron, that worked!
>>>
>>> > 4704 examples, 0 failures, 175 pending
>>>
>>> With code:
>>>
>>> before(:all) do
>>>   skip "Requires `xcodebuild` to be installed which is not possible on 
>>> this platform" unless FastlaneCore::Helper.is_mac?
>>>
>>> As you can see right now I duplicate the reason text, and use the
>>> condition that also triggers `skip`/metadata block:
>>> https://github.com/fastlane/fastlane/blob/c6b1ac4621941b2efe
>>> f702b923a572357c64eea9/spec_helper.rb#L68-L84
>>>
>>> Is there somehow a better way to "connect" the skip in `before` to the
>>> filters/metadata defined here?
>>> It would be nicer if I could e.g. call a function with the "metadata"
>>> ("xcodebuild") as parameter to trigger the skip or something. Any idea?
>>> Best,
>>> Jan
>>>
>>>
>>>
>>> Am Mittwoch, 20. Dezember 2017 02:11:56 UTC+1 schrieb Myron Marston:
>>>>
>>>> Unfortunately, there’s no way to use :skip metadata at the group level
>>>> to skip before(:all) hooks. That’s because of how metadata in RSpec is
>>>> modeled, and how RSpec implements :skip. :skip metadata is handled at
>>>> the level of individual examples, and metadata is inherited from a group to
>>>> its enclosing examples. So, for example, this works:
>>>>
>>>> RSpec.describe MyClass, :skip do
>>>>   it("is skipped"){ }
>>>>   it("is also skipped") { }end
>>>>
>>>> Both examples will be skipped here.
>>>>
>>>> But consider that you can also do this:
>>>>
>>>> RSpec.describe MyClass, :skip do
>>>>   it("is skipped"){ }
>>>>   it("is also skipped") { }
>>>>   it("is not skipped", skip: false) { }end
>>>>
>>>> Here we have on example that is overriding the skip: true metadata
>>>> inherited from the group. As a result, a before(:all) hook can’t
>>>> simply look at the group metadata to decide whether or not to skip or not.
&

Re: [rspec] How to get the number of tests excluded by `c.filter_run_excluding`?

[Myron Marston]

There is a way you can simplify this further:

module HookOverrides
  def before(*args)
super unless metadata[:skip]
  endend
RSpec.configure do |c|
  c.extend HookOverridesend

This overrides before so that it’s a no-op if :skip metadata is set on the
example group. With that in place, you don’t need to call skip from your
before(:all) hooks. But bear in mind that if you ever set :skip on an
example group (to set a default for the group) and then set skip: false for
a specific example in the group…this override will cause the before hook to
be skipped even though you’d probably expect it in that case. (Which is why
we can’t apply this as a generic patch to RSpec itself).

HTH,
Myron
​

On Tue, Dec 19, 2017 at 5:45 PM, Jan P.  wrote:

> Thanks Myron, that worked!
>
> > 4704 examples, 0 failures, 175 pending
>
> With code:
>
> before(:all) do
>   skip "Requires `xcodebuild` to be installed which is not possible on 
> this platform" unless FastlaneCore::Helper.is_mac?
>
> As you can see right now I duplicate the reason text, and use the
> condition that also triggers `skip`/metadata block:
> https://github.com/fastlane/fastlane/blob/c6b1ac4621941b2efef702b923a572
> 357c64eea9/spec_helper.rb#L68-L84
>
> Is there somehow a better way to "connect" the skip in `before` to the
> filters/metadata defined here?
> It would be nicer if I could e.g. call a function with the "metadata"
> ("xcodebuild") as parameter to trigger the skip or something. Any idea?
> Best,
> Jan
>
>
>
> Am Mittwoch, 20. Dezember 2017 02:11:56 UTC+1 schrieb Myron Marston:
>>
>> Unfortunately, there’s no way to use :skip metadata at the group level
>> to skip before(:all) hooks. That’s because of how metadata in RSpec is
>> modeled, and how RSpec implements :skip. :skip metadata is handled at
>> the level of individual examples, and metadata is inherited from a group to
>> its enclosing examples. So, for example, this works:
>>
>> RSpec.describe MyClass, :skip do
>>   it("is skipped"){ }
>>   it("is also skipped") { }end
>>
>> Both examples will be skipped here.
>>
>> But consider that you can also do this:
>>
>> RSpec.describe MyClass, :skip do
>>   it("is skipped"){ }
>>   it("is also skipped") { }
>>   it("is not skipped", skip: false) { }end
>>
>> Here we have on example that is overriding the skip: true metadata
>> inherited from the group. As a result, a before(:all) hook can’t simply
>> look at the group metadata to decide whether or not to skip or not. In
>> general, before(:all) hooks have lots of gotchas like this because they
>> don’t really fit well into the per-example semantics of so many parts of
>> RSpec. If you can refactor your tests to no longer need such a hook
>> (possibly using a aggregate_failures
>> <https://relishapp.com/rspec/rspec-core/docs/expectation-framework-integration/aggregating-failures>),
>> that is worth considering. Besides that, the other option you can do is to
>> manually call the skip method from your before(:all) hook:
>>
>> before(:all) do
>>   skip "reason to skip" if should_skip?
>>   # rest of your hook logicend
>>
>> HTH,
>> Myron
>> ​
>>
>>
>>
>> On Tue, Dec 19, 2017 at 3:47 PM, Jan P.  wrote:
>>
>>> Jon, I tried
>>>
>>> describe "xcpretty reporter options generation", requires_xcodebuild: true 
>>> do
>>>
>>>
>>> and
>>>
>>> before(:all), requires_xcodebuild: true do
>>>
>>>
>>> and
>>>
>>>
>>> describe Scan::XCPrettyReporterOptionsGenerator, requires_xcodebuild: true 
>>> do
>>>
>>>
>>> but all didn't work and the tests were logged as failure because of the
>>> `before` being executed.
>>>
>>> Am I doing this wrong somehow?
>>>
>>>
>>> Code (last iteration) is here:
>>> https://github.com/fastlane/fastlane/blob/janpio-mark_skippe
>>> d_tests_as_pending_with_reason/scan/spec/xcpretty_reporter_
>>> options_generator_spec.rb
>>> https://github.com/fastlane/fastlane/blob/janpio-mark_skippe
>>> d_tests_as_pending_with_reason/spec_helper.rb#L68-L83
>>> Matching Circle CI run:
>>> https://circleci.com/gh/fastlane/fastlane/12586
>>>
>>> -Jan
>>>
>>>
>>>
>>> Am Dienstag, 19. Dezember 2017 23:05:53 UTC+1 schrieb Jon Rowe:
>>>>
>>>> You should be able to specify `requires_xcodebuild:

Re: [rspec] How to get the number of tests excluded by `c.filter_run_excluding`?

[Myron Marston]

Unfortunately, there’s no way to use :skip metadata at the group level to
skip before(:all) hooks. That’s because of how metadata in RSpec is
modeled, and how RSpec implements :skip. :skip metadata is handled at the
level of individual examples, and metadata is inherited from a group to its
enclosing examples. So, for example, this works:

RSpec.describe MyClass, :skip do
  it("is skipped"){ }
  it("is also skipped") { }end

Both examples will be skipped here.

But consider that you can also do this:

RSpec.describe MyClass, :skip do
  it("is skipped"){ }
  it("is also skipped") { }
  it("is not skipped", skip: false) { }end

Here we have on example that is overriding the skip: true metadata
inherited from the group. As a result, a before(:all) hook can’t simply
look at the group metadata to decide whether or not to skip or not. In
general, before(:all) hooks have lots of gotchas like this because they
don’t really fit well into the per-example semantics of so many parts of
RSpec. If you can refactor your tests to no longer need such a hook
(possibly using a aggregate_failures
<https://relishapp.com/rspec/rspec-core/docs/expectation-framework-integration/aggregating-failures>),
that is worth considering. Besides that, the other option you can do is to
manually call the skip method from your before(:all) hook:

before(:all) do
  skip "reason to skip" if should_skip?
  # rest of your hook logicend

HTH,
Myron
​



On Tue, Dec 19, 2017 at 3:47 PM, Jan P.  wrote:

> Jon, I tried
>
> describe "xcpretty reporter options generation", requires_xcodebuild: true do
>
>
> and
>
> before(:all), requires_xcodebuild: true do
>
>
> and
>
>
> describe Scan::XCPrettyReporterOptionsGenerator, requires_xcodebuild: true do
>
>
> but all didn't work and the tests were logged as failure because of the
> `before` being executed.
>
> Am I doing this wrong somehow?
>
>
> Code (last iteration) is here:
> https://github.com/fastlane/fastlane/blob/janpio-mark_
> skipped_tests_as_pending_with_reason/scan/spec/xcpretty_
> reporter_options_generator_spec.rb
> https://github.com/fastlane/fastlane/blob/janpio-mark_
> skipped_tests_as_pending_with_reason/spec_helper.rb#L68-L83
> Matching Circle CI run:
> https://circleci.com/gh/fastlane/fastlane/12586
>
> -Jan
>
>
>
> Am Dienstag, 19. Dezember 2017 23:05:53 UTC+1 schrieb Jon Rowe:
>>
>> You should be able to specify `requires_xcodebuild: true` on the
>> describe as we’ll to prevent the before all being triggered
>>
>> Jon Rowe
>> ---
>> ma...@jonrowe.co.uk
>> jonrowe.co.uk
>>
>> On Wednesday, 20 December 2017 at 05:56, Jan P. wrote:
>>
>> Excuse the terrible code formatting, seems Google Groups wanted to be
>> helpful.
>>
>> Another try:
>>
>> describe Scan do
>>   describe Scan::XCPrettyReporterOptionsGenerator do
>> before(:all) do
>>   // code that fails when executed on non-macOS
>> end
>>
>> describe "xcpretty reporter options generation" do
>>   it "generates options for the junit tempfile report required by scan", 
>> requires_xcodebuild: true do
>> ...
>>
>> -J
>>
>>
>> Am Dienstag, 19. Dezember 2017 19:55:45 UTC+1 schrieb Jan P.:
>>
>> Yes, that works mostly like expected:
>>
>>
>> 4704 examples, 21 failures, 154 pending
>>
>>
>> and
>>
>> ...
>> [18:39:20]: ▸ Pending: (Failures listed here are expected and do not
>> affect your suite's status)
>> [18:39:20]: ▸ 1) Fastlane Fastlane::EnvironmentPrinter contains main
>> information about the stack
>> [18:39:20]: ▸ # Requires Xcode to be installed which is not possible on
>> this platform
>> [18:39:20]: ▸ # ./fastlane/spec/env_spec.rb:28
>> [18:39:20]: ▸ 2) Fastlane Fastlane::EnvironmentPrinter
>> FastlaneCore::Helper.xcode_version cannot be obtained contains stack
>> information other than Xcode Version
>> [18:39:20]: ▸ # Requires Xcode to be installed which is not possible on
>> this platform
>> [18:39:20]: ▸ # ./fastlane/spec/env_spec.rb:47
>> ...
>>
>>
>> Awesome!
>>
>>
>> The 21 failures are new though.
>>
>> I have a _spec.rb file with 21 examples that has a *before(:all)* that
>> seems to have been filtered with my old solution, but with *skip *is now
>> executed and fails:
>>
>> describe Scan do
>> describe Scan::XCPrettyReporterOptionsGenerator do
>> before(:all) do
>> .. code that fails when executed on non-macOS ...
>> end
>>
>> d

Re: [rspec] How to get the number of tests excluded by `c.filter_run_excluding`?

[Myron Marston]

RSpec does not provide a way to get the number of examples that were
excluded by its inclusion or exclusion filters, but there’s a different
mechanism that will do what you want. Instead of filtering the examples
(which excludes them from consideration entirely), you can skip them, which
prevents the body of the example from running, sets the example’s status to
:pending, will print the example in yellow in the formatter output, and
will count the example in the summary total printed at the end (e.g. “500
examples, 0 failures, 20 pending”). Normally, :skip metadata will cause an
example to be skipped
,
but you’ve overwritten it to cause :skip to cause examples to be filtered
out.

Here’s my suggestion for how to wire this up.

First, tag any examples that depend upon xcode with :uses_xcode (rather
than :skip), e.g.:

it "uses a feature of xcode", :xcode do
  # ...end

it "does not use xcode at all" do
  # ...end

Then use define_derived_metadata to automatically tag these examples with
:skip if you are not running on OS X:

# spec_helper.rbrequire 'rbconfig'
RSpec.configure do |config|
  unless RbConfig::CONFIG['host_os'] =~ /darwin/
config.define_derived_metadata(:xcode) do |meta|
  meta[:skip] = "Can only be run on OS X"
end
  endend

The “Can only be run on OS X” bit will be printed in the output as the
reason the examples are pending.

HTH,
Myron
​


On Tue, Dec 19, 2017 at 3:06 AM, Jan P.  wrote:

> RSpec has this nice method to exclude individual tests/examples or whole
> groups by using filter_run_excluding in the config, then tagging the
> examples:
>
> https://relishapp.com/rspec/rspec-core/v/3-7/docs/
> filtering/exclusion-filters
>
> RSpec.configure do |c|
>   c.filter_run_excluding :skip => trueend
> RSpec.describe "something" do
>   it "does one thing" do
>   end
>
>   it "does another thing", :skip => true do
>   endend
>
> "does one thing" will be checked,
> "does another thing" will not.
>
>
> We are using this, for example, to skip some tests depending on the
> platform the test is run on by wrapping the c.filter_run_excluding :skip
> => true in an if block:
>
> If Mac,
>no exclusions, if Ubuntu,
>exclude tests that do something with Xcode.
>
>
> Right now the numbers of passing examples/test is just lower if the
> exclusion filter is used, but it would be nice to see the actual number of
> tests that are skipped.
>
> Is there a way to get the number of tests skipped by this method during a
> test run?
>
> Thanks,
>
> Jan
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/3108ef8e-303d-425b-9b00-ab83dfec7633%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmuD4XwYx9MAGgAKhv-VO6GxOBK3hop9TOzbD2MBw-2Ctg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Dynamic subject in example groups

[Myron Marston]

In a subject block, you can access the example (and it’s metadata) by
adding a block argument. So if you wanted to define a subject based on the
described_class and the group description, you could do:

subject { |ex| described_class.fields[ex.metadata[:example_group][:description]]
}

To take this a step further, you could define this in a shared context to
make it easy to apply this to multiple example groups:

RSpec.shared_context "dynamic field subject" do
  subject { |ex|
described_class.fields[ex.metadata[:example_group][:description]] }
end

Then you can include this by using include_context:

RSpec.describe Types::Event do
  describe "latitude" do
include_context "dynamic field subject"
# ...
  endend

Taking this a step further, if you wanted to auto-include the shared
context, you can do so using config:

RSpec.configure do |config|
  config.include_context "dynamic field subject",
:needs_dynamic_field_subjectend

Any group tagged with :needs_dynamic_field_subject will automatically have
this context included. You could even use define_derived_metadata to
automatically tag the desired groups with : needs_dynamic_field_subject:

RSpec.configure do |config|
  config.define_derived_metadata do |meta|
meta[:needs_dynamic_field_subject] if satisfies_your_criteria?(meta)
  endend

(The definition of satisfies_your_criteria? is left as an exercise to the
reader).

All that said: once you’ve done all that, things are wired up in a pretty
implicit manner, which can become quite confusing. The power is there in
RSpec to do this, but it doesn’t necessarily mean you should. Think
carefully about the tradeoffs involved and if it is the right solution for
your project.

My book Effective Testing with RSpec 3
 has a lot
more detail about this stuff if you want to know more.

HTH,
Myron
​

On Mon, Dec 4, 2017 at 8:10 AM, Steve V  wrote:

> how can I dynamically set the subject for a spec? I have a bunch of
> describe blocks that set the subject like this `subject {
> Types::Event.fields['latitude'] }`, where `Types::Event` is the
> `described_class`. The name of the describe block in this case is
> 'latitude'.
>
> Is there a way to get that name from the group, and set it on the subject,
> or maybe do something using a metadata flag?
>
> Thanks,
> Steve
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/1a3c2601-4e41-4ab6-8085-2cf3ae2e9676%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtweXUOBgAqe6950PGNGcKSidGCjXb0fqaohoKfpXMfLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: rspec run is a failure, but returns exit code 0

[Myron Marston]

RSpec, as of v3.0, no longer uses at_exit (unless you require rspec/autorun—but
that’s not necessary if you’re using the rspec command), so I’m not
surprised the monkey patch to at_exit doesn’t work to fix your problem.

RSpec sets the exit code here:

https://github.com/rspec/rspec-core/blob/v3.6.0/lib/rspec/core/runner.rb#L45-L46

You can try adding some puts statements to your local copy of the RSpec
source to debug it (bundle show rspec-core should show you where it’s
installed). My guess is that you have some code either in your project or
in a dependency that also calls exit or exit!, or that calls at_exit and
interferes with the exit code in some fashion. If you don’t find any code
doing this, my suggestion is to apply a binary search technique to your
codebase. Define a simple, small spec file that always fails like:

require 'spec_helper' # not needed if you have `--require spec_helper`
in `.rspec`
RSpec.describe "Failure" do
  it "fails" do
expect(1).to eq 2
  endend

Run just that spec file and see what the exit code is. If it’s zero, it
means it’s something loaded by spec_helper that’s interfering. Comment out
half of spec_helper and repeat until you identify it. If it was non-zero,
it means it’s something being loaded by your other spec files (or in one of
the spec files) causing it. Try systematically loading (or deleting,
assuming you are using source control) different halves of your spec files
to see if you can identify where the issue is.

Please let us know if you find the issue, as it can help others in the
future!

Myron
​

On Thu, Oct 5, 2017 at 6:29 AM, JQN  wrote:

> I just wanted to add that the test is a failure because the element that
> the 'expect' was looking for was not found so it is an error.
>
> On Thursday, October 5, 2017 at 1:36:12 PM UTC+1, JQN wrote:
>>
>> When i run multiple specs using rspec and one of the examples is a
>> failure, the exit code that is returned is 0 than 1, but rspec report is
>> correct in reporting example failures.
>> Few articles mention that this is because of a bug in ruby and to add a
>> monkey patch
>> e.g .http://www.davekonopka.com/2013/rspec-exit-code.html
>>
>> but this does not work for me either. I would appreciate any help.
>>
>> Regards
>>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/d196d5bf-b887-4625-a23e-58b7409cbfe9%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmu1a72fqF46%3DVbxpO%2B2RJUJNuhgmX98V_eL2UX3ECmo4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: New RSpec book: Effective Testing with RSpec 3

[Myron Marston]

We have a forum for the book here:

https://forums.pragprog.com/forums/385

On Thu, Oct 5, 2017 at 7:24 AM, k m  wrote:

> I am going thru the book may i ask questions here or where is the
> preferred place.
>
> On Wednesday, March 29, 2017 at 9:47:11 AM UTC-7, Myron Marston wrote:
>>
>> Ian Dees and I have been working on new RSpec book for The Pragmatic
>> Programmers for over 2 years.  The book is available in beta now, with the
>> print version expected to ship in June.  I think this will be a very
>> helpful resource to anyone learning RSpec or anyone who wants to get the
>> most value out of it.  If you buy the beta eBook, you'll get all the
>> updates and you can give us feedback before it's published.
>>
>> https://pragprog.com/book/rspec3/effective-testing-with-rspec-3
>>
>> Myron
>>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/d607a4bc-f5c2-49dd-ad9c-3c5d72b0a5e8%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/d607a4bc-f5c2-49dd-ad9c-3c5d72b0a5e8%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsq0GRqb0NdGzofVFVqCP5YngDHLPfmqKXOzk4Esmmq_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Why when uncommenting "config.disable_monkey_patching!" RSpec prefix is mandadory ?

[Myron Marston]

For a bare top-level describe to work, RSpec has to monkey patch some
objects it does not own (specifically, the main object, and the Module
class). The config.disable_monkey_patching! option turns off all of RSpec’s
monkey patching, including the describe monkey patched onto main and Module.
Thus, when you use that option, you get a NoMethodError when you try to
call Module#describe or main.describe as you are in your example.

For more info, check out our original discussion

of the option. Also, if you’re going through the new *Effective Testing
with RSpec 3: Build Ruby Apps with Confidence* book (as I suspect you are,
given the book builds an app called ExpenseTracker and it looks like that’s
what you’re working on!), there’s an explanation of this at the bottom of
page 163 and top of page 164.

HTH,
Myron
​

On Thu, Sep 21, 2017 at 7:44 AM, Javix  wrote:

> I discovered that when I uncomment *begin /end* block in the generated
> *spec_helper.rb* file my simple spec fails if I do not use RSpec prefix
> for describe blocks as follows:
>
> require 'rack/test'
>
>
> module ExpenseTracker
>   describe 'API draft' do
> include Rack::Test::Methods
>
> it 'records submitted expenses'
>   end
> end
>
>
> Error:
>
> An error occurred while loading ./spec/unit/draft_spec.rb.
>
> Failure/Error:
>
>   describe *'*API draft*'* do
>
> include *Rack*::*Test*::*Methods*
>
>
>
> it *'*records submitted expenses*'*
>
>   end
>
>
> NoMethodError:
>
>   undefined method `describe' for ExpenseTracker:Module
>
> # ./spec/unit/draft_spec.rb:4:in `'
>
> # ./spec/unit/draft_spec.rb:3:in `'
>
> No examples found.
>
>
> Finished in 0.0003 seconds (files took 0.12244 seconds to load)
>
> 0 examples, 0 failures, 1 error occurred outside of examples
>
> If I change the same spec by prefixing describe with RSpec, it works:
>
> module ExpenseTracker
>   RSpec.describe 'API draft' do
> include Rack::Test::Methods
>
> it 'records submitted expenses'
>   end
> end
>
> *expense_tracker* *git:(**unit_tests**) **✗* rspec spec/unit/draft_spec.rb
>
>
> API draft
>
>   records submitted expenses (PENDING: Not yet implemented)
>
>
> Pending: (Failures listed here are expected and do not affect your suite's
> status)
>
>
>   1) API draft records submitted expenses
>
>  # Not yet implemented
>
>  # ./spec/unit/draft_spec.rb:7
>
>
>
> Finished in 0.00194 seconds (files took 0.12484 seconds to load)
>
> 1 example, 0 failures, 1 pending
>
> Any ideas why ? Thank you.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/05b92135-d300-4f40-98ea-e7725d6e9fba%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmuU3VA9dFGa3S%3D6a2am8bUJOMbugNvARe-30zWGz3yf2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Keyword arguments and instance doubles

[Myron Marston]

>
> I guess I was hoping that when the instance double verified that the
> message matches the method signature it would determine that I was trying
> to use keyword arguments instead of a hash.


It's worth noting that keyword arguments really just a hash (plus some
syntactic sugar). Anyhow, verifying doubles do look at keyword arguments
when verifying a message you expect/allow or when you send a message to a
verifying double.  Here's an example:

``` ruby
class HTML
  def parse(body:, headers: {})
  end
end

RSpec.describe "Verifying doubles" do
  it 'verifies the keyword arguments when allowing a message' do
html = instance_double(HTML)

# this works...
allow(html).to receive(:parse).with(body: "abc", headers: {a: 1})

# ...but this triggers an "Invalid keyword arguments provided: bad_key"
error.
allow(html).to receive(:parse).with(body: "abc", headers: {a: 1},
bad_key: 1)
  end

  it 'verifies the keyword arguments when receiving a message' do
html = instance_double(HTML, parse: nil)

# this works...
html.parse(body: "abc", headers: {a: 1})

# ...but this triggers an "Invalid keyword arguments provided: bad_key"
error.
html.parse(body: "abc", headers: {a: 1}, bad_key: 1)
  end
end
```

This works as you'd expect--when allowing a message with arguments that the
method signature supports, it works, but when you allow a message with
arguments that the method signature does not support, it raises an
appropriate error.  And it behaves similarly when you send it a message.

In your original example, you had this:

``` ruby
expect(html).to respond_to(:parse).with_keywords(:body, :headers)
```

This didn't work how you expect, because the `respond_to` matcher is only
able to work off of the method signature of the `html` object (in this
case, a test double), and RSpec's verifying doubles implement the method
signature checks as _runtime_ behavior, rather than actually defining the
exact same method signature on the test double.  Essentially, the methods
defined on test doubles are all defined to accept `*args`, and then it
applies logic to those arguments at runtime to do things like the method
signature verification.  There simply isn't a simple, performant way for
test doubles to define the method signatures in the same way as you do on
normal classes.

As I said before, using a `respond_to` matcher on a test double like this
is basically just testing the test double, not testing your class.  You
could do something like this:

``` ruby
expect(HTML.new).to respond_to(:parse).with_keywords(:body, :headers)
```

...but I personally wouldn't bother with anything like that.  Such a test
seems not to have much value, IMO, and is likely to be brittle.

Myron

On Mon, Sep 18, 2017 at 11:53 PM, Steven Webb 
wrote:

> To expand further.
>
> If I'd continued using position arguments and changed from:
>
> def parse(body)
>
> to
>
> def parse(body, headers)
>
> the instance double could calls to this were using the correct number of
> arguments.
>
> Alternatively if I was already using keyword arguments and added another
> one:
>
> def parse(body:)
>
> to
>
> def parse(body:, headers: {})
>
> it would also get picked up.
>
> It's only because passing keywords arguments to a method can be
> interpreted as either a single hash or multiple arguments that this isn't
> picked up.
>
> Steve.
>
> On Tuesday, 19 September 2017 14:33:22 UTC+8, Steven Webb wrote:
>>
>> Thank you.
>>
>> I guess I was hoping that when the instance double verified that the
>> message matches the method signature it would determine that I was trying
>> to use keyword arguments instead of a hash.
>>
>> Steve.
>>
>> On Tuesday, 19 September 2017 14:20:10 UTC+8, Myron Marston wrote:
>>>
>>> What goal do you have in mind for this test? From the examples you gave,
>>> it looks like you are only testing how RSpec’s verifying doubles work. For
>>> example, this expectation:
>>>
>>> expect(html).to respond_to(:parse).with_keywords(:body, :headers)
>>>
>>> …isn’t exercising your code at all, because you’ve declared html as a
>>> test double, so it’s just testing how doubles work. If you’re trying to
>>> test the HTML class, you should not use a double in its place. Test doubles
>>> are intended for when you want to control the environment in which you test
>>> something, by replacing some collaborators with fake versions. They’re not
>>> intended to ever replace the thing you are testing—once you do that, you’re
>>> no longer testing the thing.
>>>
>>> Myron
>>> ​
>&

Re: [rspec] Keyword arguments and instance doubles

[Myron Marston]

What goal do you have in mind for this test? From the examples you gave, it
looks like you are only testing how RSpec’s verifying doubles work. For
example, this expectation:

expect(html).to respond_to(:parse).with_keywords(:body, :headers)

…isn’t exercising your code at all, because you’ve declared html as a test
double, so it’s just testing how doubles work. If you’re trying to test the
HTML class, you should not use a double in its place. Test doubles are
intended for when you want to control the environment in which you test
something, by replacing some collaborators with fake versions. They’re not
intended to ever replace the thing you are testing—once you do that, you’re
no longer testing the thing.

Myron
​

On Mon, Sep 18, 2017 at 11:03 PM, Steven Webb 
wrote:

> I'm having trouble testing a method signature change from taking a single
> argument (a hash) to using keyword arguments. I've created a contrived
> example of HTML parsing to simplify things (I'm not actually writing a html
> parser):
>
> class HTML
>   def parse(body) # body is a hash
> ...
>   end
> end
>
> I want to update it so that it can take an optional headers argument. It
> becomes:
>
> class HTML
>   def parse(body: , headers: {}) # body and headers are both hashes
>   end
> end
>
> In a related unit test of a different class I'm using something like this:
>
> RSpec.describe "calling the parser" do
>   let(:html) { instance_double("HTML", parse: nil) }
>   let(:body) { double("body") }
>   let(:headers) { double("headers") }
>
>   before { html.parse(body: body, headers: headers) }
>
>   it "allows passing optional headers" do
> expect(html).to have_received(:parse).with(body: body, headers:
> headers)
>   end
> end
>
> The problem I've got is that this test passes before updating the HTML
> class. After updating the HTML class it correctly detects the keywords as
> arguments and passes. Before it incorrectly determines the keywords are the
> "body" hash and passes. Both are valid ruby, but the method signature has
> changed (at least to me, possibly not to the VM). I tried:
>
> it "allows an optional headers argument" do
>   expect(html).to respond_to(:parse).with_keywords(:body, :headers)
> end
>
> but that fails (presumably the instance double is using method_missing).
>
>   1) calling the parser allows an optional headers argument
>  Failure/Error: expect(html).to respond_to(:parse).with_keywords(:body,
> :headers)
>expected # to respond to :parse
> with keywords :body and :headers
>  # ./spec/keyword_args_spec.rb:40:in `block (2 levels) in  (required)>'
>
> Can anyone explain how I should be testing this correctly?
>
> Thanks
>
> Steve.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/8dbe9153-45c0-44f7-a0be-e6fa6ceffd7e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsXyKTx%3DRDk0pnZksU3VZtk79Sf4jg-PBAG-55qPxRJkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[rspec] Re: New RSpec book: Effective Testing with RSpec 3

[Myron Marston]

The book has been released!  If you're wondering if the book is for you, 
check out the video we put together about it and the free excerpts:

   - Intro excerpt <https://media.pragprog.com/titles/rspec3/intro.pdf>
   - Chapter 2 (From Writing Specs to Running Them) excerpt 
   <http://media.pragprog.com/titles/rspec3/writing.pdf>
   - Chapter 6 (Getting Real: Integration Specs) excerpt 
   <http://media.pragprog.com/titles/rspec3/testing.pdf>
   - Chapter 13 (Understanding Test Doubles) excerpt 
   <http://media.pragprog.com/titles/rspec3/origins.pdf>

Myron

On Wednesday, March 29, 2017 at 9:47:11 AM UTC-7, Myron Marston wrote:
>
> Ian Dees and I have been working on new RSpec book for The Pragmatic 
> Programmers for over 2 years.  The book is available in beta now, with the 
> print version expected to ship in June.  I think this will be a very 
> helpful resource to anyone learning RSpec or anyone who wants to get the 
> most value out of it.  If you buy the beta eBook, you'll get all the 
> updates and you can give us feedback before it's published.
>
> https://pragprog.com/book/rspec3/effective-testing-with-rspec-3
>
> Myron
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/bffa98ea-c6b3-477c-a097-47688acf302d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] FailedExampleNotification message_lines without ANSI

[Myron Marston]

The message lines include two parts:

   - The english language parts (like "Failure/Error", and the failure
   message from the matcher)
   - The extracted code snippet (the `TestClass.test_method` part).

For the extracted code snippet, we use coderay to syntax highlight it if
that gem can be loaded.  For the english language part, RSpec applies the
color highlighting (but only when you call `colorized_message_lines`).

We should probably fix `message_lines` so that it doesn't apply coderay to
the snippet, while `colorized_message_lines` should.  Can you open an issue
on rspec-core about this?

Myron

On Thu, Sep 14, 2017 at 10:06 PM, Dylan Reichstadt <
dylan.reichst...@gmail.com> wrote:

> Hey All,
>
> I'm trying to export data from RSpec, including the failing lines of code.
> In the FailedExampleNotification
> ,
> I noticed there were two methods:
>
>- message_lines
>- colorized_message_lines.
>
> Despite the name differences, both of these methods look to return ANSI
> color characters, with message_lines slightly less (see below). I was
> expecting colorized_message_lines to do that, but not message_lines.
>
> Is there a public method that exposes this data without the ANSI? I'll
> look to regex them out, but if there's another method that's more reliable,
> I would love to know.
>
> Thanks!
>
> RSpec Version: 3.6.0
>
>
> notification.message_lines
> => ["Failure/Error: \e[0m\e[1;34;4mTestClass\e[0m.test_method",
>  "  expected to find css \"thisisatest\" but there were no matches"]
>
> notification.colorized_message_lines
> => ["\e[31mFailure/Error: \e[0m\e[1;34;4mTestClass\e[0m.test_method\e[0m",
>  "\e[31m  expected to find css \"gjiegeij\" but there were no
> matches\e[0m"]
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/3f5fd029-9bed-4dde-bac5-f76fe0d9ce9c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtiSYvKvfc2dWDxCRMcoCDRfV0G_iyV8i5FrjF%3D_tQO2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] configure warning stream to be different from error stream

[Myron Marston]

RSpec does not provide a way to do this.  Ruby controls its warnings, and
controls where it goes.  You can redirect $stderr to a file or other IO
using `$stderr.reopen(file_or_io)`.

HTH,
Myron

On Wed, Sep 6, 2017 at 12:43 AM, JQN  wrote:

> 0 Is it possible to direct warnings to a different stream than the
> default error stream? I can see there is a configuration option for
> deprecation_warnings  to be able to output to a different stream but i
> would like to do this for all warnings
> 
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/2c531e38-0a04-4965-be5c-329dc3d0270c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmu-HM9KLfHKhHQrAzHQ9%2BM7LU9iHdg41JV4fafiDdgL0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] End to End Testing Best Practices?

[Myron Marston]

I don’t have sufficient information to tell you what I’d do in this
situation, but here are some general principles to help you think through
the tradeoffs here.

   - Whether or not I’d create a user schema per example really depends on
   how long that operation takes. If it’s a pretty quick operation (e.g.
   milliseconds) I’d probably just make one per example; since these are
   end-to-end tests they’re expected to be slow and doing something like a
   before(:context) hook caries a high maintenance cost since it has so
   many caveats compared to a typical before(:example) hook.
   - I personally don’t follow the “one expectation per example” rule at
   all. It was a useful corrective to poorly written tests that contained tons
   of expectations and were hard to debug, but bears a high cost (much higher
   than I’m willing to pay) due to all the time wasted repeating setup. In
   fast, isolated unit tests, I do follow a principle I’d call “one behavior
   per example” (where a single behavior can often be specified with a single
   expectation, but not always). I care a lot about keeping a fast, snappy
   test suite so in slower integration or acceptance tests I write much
   courser-grained tests that may encapsulate a whole workflow.
   - I tend to use :aggregate_failures for all my integration and
   acceptance tests.
   - If a user schema can safely be re-used in many examples, and creation
   of the schema was slow enough to warrant sharing it among multiple
   examples, I’d probably use a different approach than a before(:context)
   hook. Instead, I’d probably do something like this:

# spec/spec_helper.rbmodule UserSchemaCache
  def self.schema
@schema ||= SecureRandom.uuid.tap do |schema_name|
  SchemaService.new.create_schema(schema_name)
end
  endend
RSpec.configure do |config|
  config.when_first_matching_example_defined(:needs_schema) do
UserSchemaCache.schema
  endend

# some_spec.rb
RSpec.describe 'Authentication', :needs_schema do
  # ...end

That allows you to use the same user schema among all your end-to-end
examples, incurring the cost of creating it only once. The
when_first_matching_example_defined hook is only invoked if there’s an
example matching :needs_schema, so there’s no cost when running your other
specs.

HTH,
Myron
​

On Tue, Aug 1, 2017 at 5:34 PM, Jon Gordon  wrote:

> Hello again Myron :)
>
> I'm guessing that's why I couldn't find many before(:all) examples online.
> I wasn't aware of aggregate_failures, that's pretty cool feature! I always
> tried to follow the 'single assertion per test' principle. However, the
> example above is small portion of a bigger Spec. In the same Spec file I
> will also try to delete an entity (which require me to create an entity
> first), get a list of entities (create at least 2 entities) and expect
> exception to get raised when I'm trying to create an entity that I already
> created. All of those require a working schema. I can't group all up them
> under a single aggregate_failures test. So sadly, I will have to use
> instance variable, or to wrap a set block like the example you shared above
> (unless you have another idea)
>
> But I'm wondering, let's say I could control every point in the process
> and design this whole spec from scratch, having the option to do whatever I
> want on each of the remote micro-services. What would be the proper way of
> addressing it? Doesn't feel like the tests above are something specials,
> more like a standard REST service testing. Here's the option I can think
> about:
>
> 1. Create the schema over and over each test with 'before' block like so :
>
> let(schema_name) { SecureRandom.uuid.to }
>
> before
>   user_schema.create_schema(schema_name)
> end
>
> it 'my test' do
>   puts schema_name
> end
>
> This will be slower as schema will getting created every-test, and I only
> really need a single one as the schema is just a dependency and no the main
> focus of the test. But - perhaps clearer to read and avoid sharing context
> with before(:all).
>
> 2. Pre-populate the remote test database with default user schema with
> default name. I can either create it directly on the database when I spin
> the environment or from spec_helper . I can even store the default values
> in YML file, create an object from it (config) and use it on test.
>
>  payload = JSON.parse(File.read('spec/acceptence/fixtures/feature.json'))
>  payload['schema_name'] = config(:default_schema_name)
>
> This however makes the test less clear because not all information is
> being exposed when you read just the spec file. I would like to do it the
> 'proper' way - as I can probably talk with the other teams in the future -
> makes those

Re: [rspec] End to End Testing Best Practices?

[Myron Marston]

chema(schema_name)
>>   payload = JSON.parse(File.read('spec/acc
>> eptence/fixtures/feature.json'))
>>   payload['schema_name'] = schema_name
>>
>>   subject.create_user(user: 'my_user', payload: payload)
>>
>>   response = subject.get_user_by_category(category: payload[
>> 'category'])
>>   remote_entity = JSON.parse(response.body)
>>
>>   expect(payload.to_json).to eq(
>> remote_entity['list'][unique_value]
>>   )
>> end
>>   end
>> end
>>
>> To keep it dry, I should be moving the whole schema creation into a
>> before block:
>>
>> before
>>   schema_name = SecureRandom.uuid.to
>>   user_schema.create_schema(schema_name)
>> end
>>
>> Before makes sense to me over let here, because it's an action. However,
>> because the schema is more of a 'pre-condition', I can create it just once,
>> and avoid multiple schema in my database. Therefore, before(:all) seems
>> like a better option.
>>
>> before(:all)
>>   schema_name = SecureRandom.uuid.to_s
>>   user_schema.create_schema(schema_name)
>> end
>>
>> Now that problem is that when I create user in my examples, I NEED to
>> schema name, so I need to share context between the before and it block. It
>> makes sense for me to do it like so:
>>
>> let(:schema_name) { SecureRandom.uuid.to_s }
>>
>> before(:all)
>>   user_schema.create_schema(schema_name)
>> end
>>
>> Then I can create easily create user in my example like so:
>>
>> payload = JSON.parse(File.read('spec/acceptence/fixtures/feature.json'))
>> payload['schema_name'] = schema_name
>>
>> subject.create_user(user: 'my_user', payload: payload)
>>
>> Alas, this will not work. As it not allowed by RSpec to use  a let value
>> inside a before(:all) block. So I need to hold a string that can be used in
>> both the it and before block. It can solved it by defining a Constant or
>> using Instance variable but both methods feels reek to me. I mentioned I
>> don't have access to the database (as those are remote machines and they
>> don't expose the ip for that database) so I can't truncate the db
>> information and avoid the before block here.
>>
>> Thanks!
>>
>> On Thursday, July 20, 2017 at 10:57:05 AM UTC+3, Jon Gordon wrote:
>>
>> Not in Unit-tests of-course, but It seems like the only option in real
>> end-to-end testing. The system is quite complex, as it's basically a set of
>> couple micro-services. Each has it's own unique database (Can be Postgress,
>> Casanda, Oracle...). In a single End to End test, all databases are
>> populated with information. Clearing tables between each test can take
>> time, and is quite complex. The CI process does re-start the containers at
>> the very start of the test-run (so it's like restarting them to a fresh
>> state), but not during tests.
>>
>> if I'll take the list of music instruments in the Faker gem for example,
>> It only has around 10 options. So even if I use the unique flag - It will
>> run out of options after 10 test-cases.  I guess use 'msuic instruments'
>> in one spec file, and 'cat-names' on the other to avoid it, but that means
>> I need to 'remember' what pool of string I already used in previous tests,
>> and that's feel even worse for me.
>>
>> Thanks.
>>
>>
>>
>> but I thought that there no better way around it. Because
>>
>> On Thursday, July 20, 2017 at 3:29:25 AM UTC+3, Myron Marston wrote:
>>
>> In general, if you need absolutely unique strings, `SecureRandom.uuid` is
>> a good way to get one.  UUIDs are universally unique, after all :).
>>
>> That said, the fact that you are running out of unique random strings
>> from faker is concerning.  All tests should work off of a "clean slate" in
>> your database, either by wrapping each test in a rolled-back transaction,
>> or by truncating your DB tables.  Are you "leaking" DB records between
>> tests?
>>
>> Myron
>>
>> On Wed, Jul 19, 2017 at 12:42 PM, Jon Gordon  wrote:
>>
>> Hi Myron,
>>
>> I will definitely check the book - looks like it's perfect for RSpec
>> beginner. Also, thanks for sharing the example online - that's alone can
>> give me a good starting base :)
>>
>> I will ask another question while posting -  for unit-test

Re: [rspec] How to programmatically find example/example group run status

[Myron Marston]

You can't use a hook to accurately capture the result of each spec because
hooks are essentially part of each spec.  An example isn't done (and it's
status isn't set) until all of its hooks have run, because a failure in an
`after` hook must fail the example.

If you want to observe the result of each spec, a custom formatter is the
way to go.  What you do with the status of each example in your custom
formatter is entirely up to you, based on your needs.

Myron

On Fri, Jul 28, 2017 at 9:14 PM, JQN  wrote:

> Hi Myron
>
> I am trying to capture each example execution result  in a
> rspec.config.after(:each)  block so I could output it to a third party test
> result object.
> but if an example fails during rspec.load() , the config.after(:each)
> block is not executed, neither is config.around(), but the example is
> correctly marked as a failure in the rspec output. How can I successfully
> capture the execution result for each example no matter how/where it
> fails/errors as soon as the failure happens.When an example fails can I
> inject the execution status as a value in the examplegroup metadata so I
> could refer it in a config.after(:all) block as this does seem to always
> execute.
>
> I have had time to learn about this more and I think a custom formatter is
> a way to go and when an example fails i could inject a key value pair into
> the related examplegroup metadata. Am I on the right path ?
>
>
> On Friday, July 28, 2017 at 2:12:24 PM UTC+1, Myron Marston wrote:
>>
>> Hi JQN,
>>
>> It's not clear to me what you are trying to accomplish.  Can you explain
>> a bit more about what you're trying to do?
>>
>> Thanks,
>> Myron
>>
>> On Fri, Jul 28, 2017 at 1:23 AM, JQN  wrote:
>>
>>> I am using rspec 3.5.0 and rspec-core 3.5.4.In earlier version I see
>>> that there are Formatter classes like JSONFormatter in rspec core are
>>> methods like failed_count and  these methods are not present in the newer
>>> versions.I couldn't figure out a way to obtain an example run status
>>>
>>> For examples that run ok, i can look at the example metadata /
>>> execution_result in after(:each) but some of my examples fail due to load
>>> errors and the after(:each) block is not reached. There is execution
>>> results populated in a file/standard output correctly but I would like to
>>> dynamically inspect as well.
>>>
>>> Please advise!
>>>
>>> --
>>> 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/ms
>>> gid/rspec/0f2bb5d5-ab61-4559-a871-ce7b7b72577b%40googlegroups.com
>>> <https://groups.google.com/d/msgid/rspec/0f2bb5d5-ab61-4559-a871-ce7b7b72577b%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/f64810dd-25bc-4a23-bc82-583245524a0b%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/f64810dd-25bc-4a23-bc82-583245524a0b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtX5EbfWAdS2%3DhopkYxV7c_-eKi-PB0Gj7%2BoB1gXd_QHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] How to programmatically find example/example group run status

[Myron Marston]

Hi JQN,

It's not clear to me what you are trying to accomplish.  Can you explain a
bit more about what you're trying to do?

Thanks,
Myron

On Fri, Jul 28, 2017 at 1:23 AM, JQN  wrote:

> I am using rspec 3.5.0 and rspec-core 3.5.4.In earlier version I see that
> there are Formatter classes like JSONFormatter in rspec core are methods
> like failed_count and  these methods are not present in the newer
> versions.I couldn't figure out a way to obtain an example run status
>
> For examples that run ok, i can look at the example metadata /
> execution_result in after(:each) but some of my examples fail due to load
> errors and the after(:each) block is not reached. There is execution
> results populated in a file/standard output correctly but I would like to
> dynamically inspect as well.
>
> Please advise!
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/0f2bb5d5-ab61-4559-a871-ce7b7b72577b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmu8KLKfuESyk%3DU699rBexkFKfgAaauVDc8Pzx5jZd-Y%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] End to End Testing Best Practices?

[Myron Marston]

In general, if you need absolutely unique strings, `SecureRandom.uuid` is a
good way to get one.  UUIDs are universally unique, after all :).

That said, the fact that you are running out of unique random strings from
faker is concerning.  All tests should work off of a "clean slate" in your
database, either by wrapping each test in a rolled-back transaction, or by
truncating your DB tables.  Are you "leaking" DB records between tests?

Myron

On Wed, Jul 19, 2017 at 12:42 PM, Jon Gordon  wrote:

> Hi Myron,
>
> I will definitely check the book - looks like it's perfect for RSpec
> beginner. Also, thanks for sharing the example online - that's alone can
> give me a good starting base :)
>
> I will ask another question while posting -  for unit-testing I'm using
> Faker gem to fake common strings. However, in end to end tests, we work
> against a database - so even if I'm using the 'unique' method, I'm running
> out of unique strings after a while. I'm using 'securerandom' to generate
> random number, but wondering if there's a better approach for that.
>
> Thanks!
>
> On Wednesday, July 19, 2017 at 6:33:49 PM UTC+3, Myron Marston wrote:
>>
>> My upcoming book, Effective Testing with RSpec 3
>> <https://www.google.com/url?q=https%3A%2F%2Fpragprog.com%2Fbook%2Frspec3%2Feffective-testing-with-rspec-3&sa=D&sntz=1&usg=AFQjCNHGLaAn9OUSvszwbNhLSkP9Ypy-7A>,
>> has an example of building a JSON API using end-to-end acceptance tests,
>> isolated unit tests, and integration tests.  It might fit what you're
>> looking for better since you mentioned you're looking for examples of
>> end-to-end testing of REST services.
>>
>> The code for the book is all online <https://github.com/rspec-3-book>,
>> as well.
>>
>> All that said, Xavier's screen cast is very good, and I definitely
>> recommend it, particularly if you do better with videos than printed
>> materials.
>>
>> Myron
>>
>> On Wed, Jul 19, 2017 at 4:30 AM, Jon Gordon  wrote:
>>
>>> Thanks Xavier :)
>>> I will be checking this course!
>>>
>>> Is there perhaps an open-source project with end-to-end spec tests you
>>> can recommend (REST tests are preferred, not Capybara)? something to get a
>>> reference from?
>>> Thank you.
>>>
>>> On Wednesday, July 19, 2017 at 2:24:46 AM UTC+3, Xavier Shay wrote:
>>>>
>>>> Obligatory plug for https://www.pluralsight.co
>>>> m/courses/rspec-ruby-application-testing which touches on some of the
>>>> themes you're asking about :)
>>>>
>>>>
>>>> On Tue, Jul 18, 2017, at 04:06 PM, Jon Rowe wrote:
>>>>
>>>> Hi Jon
>>>>
>>>> A couple of tips, firstly you can stub out your external dependencies
>>>> for an end to end test, it just depends on the level of integration you
>>>> want, it’s equally fine to do what you propose. For injecting your endpoint
>>>> (IP, hostname or otherwise) you have a couple of ways of doing it, the
>>>> simplest is to use environment variables e.g. `ENV[‘API_ENDPOINT’]`, or you
>>>> can build yourself a config system like you mention. The reason why you
>>>> don’t see big projects using external configuration files is it is usually
>>>> done at the app level rather than in rspec.
>>>>
>>>> If you chose to go down the config file route, xml, yml or otherwise,
>>>> you’d be better off loading it in a spec_helper or other such support file,
>>>> and assigning it somewhere.
>>>>
>>>> Personally I would go with json fixture files for static json, or a
>>>> generator method if it needs to be dynamic.
>>>>
>>>> Cheers.
>>>> Jon
>>>>
>>>> Jon Rowe
>>>> ---
>>>> ma...@jonrowe.co.uk
>>>> jonrowe.co.uk
>>>>
>>>> On Wednesday, 19 July 2017 at 01:52, Jon Gordon wrote:
>>>>
>>>>
>>>> Hi everyone,
>>>>
>>>> I'm quite new to RSpec, and I have used it mainly for unit-testing.
>>>> Lately, a need for a small number of end-to-end tests became relevant. When
>>>> writing test-cases, I'm trying to stub all dependencies, but because that's
>>>> not an option when doing integration tests, I need some help to understand
>>>> what's the proper way to do things. Here's couple of questions:
>>>>
>>&

Re: [rspec] End to End Testing Best Practices?

[Myron Marston]

My upcoming book, Effective Testing with RSpec 3
, has an
example of building a JSON API using end-to-end acceptance tests, isolated
unit tests, and integration tests.  It might fit what you're looking for
better since you mentioned you're looking for examples of end-to-end
testing of REST services.

The code for the book is all online , as
well.

All that said, Xavier's screen cast is very good, and I definitely
recommend it, particularly if you do better with videos than printed
materials.

Myron

On Wed, Jul 19, 2017 at 4:30 AM, Jon Gordon  wrote:

> Thanks Xavier :)
> I will be checking this course!
>
> Is there perhaps an open-source project with end-to-end spec tests you can
> recommend (REST tests are preferred, not Capybara)? something to get a
> reference from?
> Thank you.
>
> On Wednesday, July 19, 2017 at 2:24:46 AM UTC+3, Xavier Shay wrote:
>>
>> Obligatory plug for https://www.pluralsight.co
>> m/courses/rspec-ruby-application-testing which touches on some of the
>> themes you're asking about :)
>>
>>
>> On Tue, Jul 18, 2017, at 04:06 PM, Jon Rowe wrote:
>>
>> Hi Jon
>>
>> A couple of tips, firstly you can stub out your external dependencies for
>> an end to end test, it just depends on the level of integration you want,
>> it’s equally fine to do what you propose. For injecting your endpoint (IP,
>> hostname or otherwise) you have a couple of ways of doing it, the simplest
>> is to use environment variables e.g. `ENV[‘API_ENDPOINT’]`, or you can
>> build yourself a config system like you mention. The reason why you don’t
>> see big projects using external configuration files is it is usually done
>> at the app level rather than in rspec.
>>
>> If you chose to go down the config file route, xml, yml or otherwise,
>> you’d be better off loading it in a spec_helper or other such support file,
>> and assigning it somewhere.
>>
>> Personally I would go with json fixture files for static json, or a
>> generator method if it needs to be dynamic.
>>
>> Cheers.
>> Jon
>>
>> Jon Rowe
>> ---
>> ma...@jonrowe.co.uk
>> jonrowe.co.uk
>>
>> On Wednesday, 19 July 2017 at 01:52, Jon Gordon wrote:
>>
>>
>> Hi everyone,
>>
>> I'm quite new to RSpec, and I have used it mainly for unit-testing.
>> Lately, a need for a small number of end-to-end tests became relevant. When
>> writing test-cases, I'm trying to stub all dependencies, but because that's
>> not an option when doing integration tests, I need some help to understand
>> what's the proper way to do things. Here's couple of questions:
>>
>> 1. The test requires an IP for remote machine (which is not local and
>> sadly can not be). Obviously, I shouldn't supply the IP inside the spec
>> file. The simple way is reading an external YML file with the IP (that will
>> get created automatically during the CI process with the right IP for
>> example) and populate the IP directly from it. But, I was checking couple
>> of big project that uses rspec, and I never seen an external configuration
>> file, so I'm thinking perhaps there is a better way of doing it
>>
>> 2. If indeed YML file is the right answer, I'm not sure if reading from
>> the YML file every spec file (that uses this service) is the right thing to
>> do? Shouldn't I be using hooks instead for that?
>>
>> 3. The test-object is a REST service, and some of the requests require
>> big json object. I have two options:
>> a. I can create the json object in the spec file itself (which makes
>> all information visible to you from the spec file itself, but clutters the
>> spec)
>> b. Creating an external default fixture (which is basically a json
>> file), read from it during the spec, and re-write the values that are
>> relevant for the specific tests.
>>
>> Thank you!
>>
>>
>> --
>> 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/ms
>> gid/rspec/61ac9ade-1045-4211-80d3-441ef01ae7cb%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> 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/ms
>> gid/rspec/3FF6FCF2018A482CBDC70C02BAFFB643%40jonrowe.co.uk
>> 

Re: [rspec] Updates to my RSpec for Rails testing book available

[Myron Marston]

Congrats, Aaron!  It's always nice to have more material that's current
against the latest version of RSpec.

Myron

On Wed, Jun 21, 2017 at 6:10 AM, Aaron Sumner  wrote:

> Hi, please forgive the self-promotion, but I wanted to share that I've
> begun rolling out updates to my book, Everyday Rails Testing with RSpec.
> It's a serious rewrite, accounting for RSpec 3.6, Rails 5.1, and how my
> approach to testing has evolved over the last few years. You may find it to
> be a nice companion to Myron's new book. Mine's not as comprehensive, but
> focuses more on what rspec-rails gives you, and on the tools I use most—the
> 20% of RSpec and friends that I use 80% of the time.
>
> https://leanpub.com/everydayrailsrspec
>
> It's a free update if you already own a copy, and of course I won't turn
> down any new readers :)
>
> Thanks,
> Aaron
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/4d11ef31-c162-4602-ba9a-3137ef4bee5c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsuTxjrFnh7pWpS2jGmGEyjXr%2BiPQH1fJqnowB%2BRTWrxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] How to hide private methods from included Helper module

[Myron Marston]

RSpec isn't doing anything special to create the behavior you're
describing, and there's nothing we can do to prevent it. It's simply how
Ruby modules and private methods work.  Private methods are can be called
as long as the implicit `self` receiver -- which means a private method
from a superclass can be called from a subclass.  Module inclusion puts the
module into the ancestor chain of the including class, effectively making
the module a superclass, allowing private methods in the module to be
called from the including class.

HTH,
Myron

On Sat, May 6, 2017 at 9:18 AM, Evan Brodie  wrote:

> Hello,
>
> In the application that I am working on, the rspec configuration includes
> several modules that are "mixed-in" to rspec via config.include, in an
> RSpec.configuration block. This would make all the instance methods of
> that module available to my test classes. For example, I have the following
> helper to abstract some of the login functionality in my acceptance tests:
>
> module LoginHelper
>   def login(user)
> # Insert login logic here
>   end
> end
>
>
> The implementation of the login method has begun to grow and is starting
> to include some duplicated code, so I naturally want to abstract some of
> this duplication out into *private methods*, to ease code readability.
> However, it appears that any private method included into my rspec
> configuration from these "mixed-in" modules will also be visible to my test
> code. I can verify this by placing a specific raise message into my private
> method and witness that specific error message appear when the test calls
> this method and ultimately fails. What I perhaps hoped was that the test
> would instead fail due to a method scope issue.
>
> I am seeking a way to have methods from these "mixed-in" modules be hidden
> from test code and only available to public methods from within its module,
> so that I do not risk having these private methods get accidentally called
> by the test code. Is there a way to accomplish this in the current version
> of rspec?
>
> Thank you.
> Evan
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/c4cebf6d-b5a8-4c20-b2e4-7aa62824c3f5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvUEM7kwe%3D5CbO_3%3DrkGCq3%2BNy%2B%3DULOie2%2B%2BLo6tWEHsg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] run tests on files changed since last commit

[Myron Marston]

RSpec does not provide anything like this (it is agnostic about what source
control system you are using, if any).

You could write a script to query git for the list of files that have
changed since last commit, and pass the spec files in that list to the
`rspec` command.

HTH,
Myron

On Sun, Apr 9, 2017 at 1:51 PM, Alon Dahari  wrote:

> Hi,
> I have a pre-commit hook on my project to run my rspec tests and prevent
> commit on failures.
> As the project grows, running the tests is getting slower.
> Is there a way to run only tests that touch files changed since last
> commit (staged files)?
>
> Thanks!
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/50c0145b-36d4-431a-a6d5-4d7faf8e87a9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmt4aqch%2BK0bcQWr1W1rSwfqQn%2Bmb4HVg4X34-FrGdX8ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[rspec] New RSpec book: Effective Testing with RSpec 3

[Myron Marston]

Ian Dees and I have been working on new RSpec book for The Pragmatic 
Programmers for over 2 years.  The book is available in beta now, with the 
print version expected to ship in June.  I think this will be a very 
helpful resource to anyone learning RSpec or anyone who wants to get the 
most value out of it.  If you buy the beta eBook, you'll get all the 
updates and you can give us feedback before it's published.

https://pragprog.com/book/rspec3/effective-testing-with-rspec-3

Myron

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/331f6465-8271-4e8f-8c10-6fda680a6843%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Stub methods with newer syntax (stub that raises and then returns)

[Myron Marston]

With the newer, non-monkey patching syntax, you would do:

allow(dbl).to receive(:raise_then_return) do
  @counter = @counter.to_i.succ
  raise RuntimeError if @counter < 2
  "foo"end

​

On Tue, Mar 28, 2017 at 1:31 PM, Joery Moinsen  wrote:

> Hello, how can i stub methods with the newer syntax? My current stub looks
> like
>
>   dbl.stub(:raise_then_return) do
> @counter = @counter.to_i.succ
> raise RuntimeError if @counter < 2
> return "foo"
>   end
>
>
> and i get a deprecation warning
>
> Deprecation Warnings:
>
> Using `stub` from rspec-mocks' old `:should` syntax without explicitly
> enabling the syntax is deprecated. Use the new `:expect` syntax or
> explicitly enable `:should` instead.
>
> The doc on Method stubs (https://www.relishapp.com/
> rspec/rspec-mocks/v/2-3/docs/method-stubs) has no equivalent for Rspec 3.5
>
>
> What is the preferred way to express my stub? I need a method that raises on 
> first call and then returns something on the second call.
>
>
> Many thanks for considering my request.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/eb57df04-8ab3-4503-8c4e-89ab5c468e4a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsy%3D8Fqktd8voYmTMV7Oa%2BSar7jDiXzTpXeymF2OB6hOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] issue deploying to heroku, rake aborted! NoMethodError: undefined method `web_console' for #

[Myron Marston]

Your error does not seem related to RSpec in any way.  Maybe someone will
have an idea and suggest a solution, but I think you will have better luck
asking on a mailing list or forum focused on Heroku, Rails, or Rake, as
those are the tools you are dealing with.

Good luck!
Myron

On Tue, Mar 14, 2017 at 11:07 AM,  wrote:

> please can someone help me. i run into this error when trying to deploy to
> heroku
>
> remote: sh: 2: Syntax error: Unterminated quoted string
> remote: sh: 2: Syntax error: Unterminated quoted string
> remote:  !
> remote:  ! Could not detect rake tasks
> remote:  ! ensure you can run `$ bundle exec rake -P` against your app
> remote:  ! and using the production group of your Gemfile.
> remote:  ! rake aborted!
> remote:  ! NoMethodError: undefined method `web_console' for
> #
>
> /language_pack/helpers/rake_runner.rb:102:in `load_rake_tasks!': Could
> not detec
> t rake tasks (LanguagePack::Helpers::RakeRunner::CannotLoadRakefileError)
> remote: ensure you can run `$ bundle exec rake -P` against your app
> remote: and using the production group of your Gemfile.
> remote: rake aborted!
> remote: NoMethodError: undefined method `web_console' for
> # Configuration
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/476022cf-2099-4cb1-8e35-b0fc9aa18aab%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQms2Urx6PgpdVkrXebFE2d%3D-Cj0ZLgXmtHVgC4w26Rdo1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] rspec runs indeterminate number of tests

[Myron Marston]

Right, I can see that here:

https://github.com/han/stalker/blob/18a725d42cbbe87361f3bc0dcad6e43a90bdc6dc/lib/stalker.rb#L112

IMO, libraries generally shouldn't do this; it should be up to the host
application to decide what to do when an error occurs.  Causing the OS
process to exit (and giving the host app no opportunity to change that) is
really constraining and problematic.  It would be much better if it raised
an exception.  That's what they are for, after all.  Can you imagine if
every library decided to force the process to exit on every error instead
of raising exceptions?

On Fri, Jan 6, 2017 at 1:14 PM, 'Dan Alvizu' via rspec <
rspec@googlegroups.com> wrote:

> I was incorrect - it was not backtickets that was the problem.
>
> I am using Stalker (https://github.com/han/stalker) and a call to
> Stalker.prep when beanstalkd was not running was causing the ruby process
> to exit
>
> On Friday, January 6, 2017 at 11:52:13 AM UTC-7, Myron Marston wrote:
>>
>> Using backticks should spawn a subshell and run the provided command. I
>> didn’t think it could cause your current ruby process to exit. Can you
>> provide more detail about what was in the backticks? And can you see if it
>> was raising an exception (via a snippet like this)?
>>
>> def safe_backticks(command)
>>   `#{command}`rescue Exception => ex
>>   puts "#{ex.class}: #{ex.message}"end
>>
>> ​
>>
>> On Fri, Jan 6, 2017 at 10:48 AM, 'Dan Alvizu' via rspec <
>> rs...@googlegroups.com> wrote:
>>
>>> Aha!
>>>
>>> Running with `--format doc` allowed me to see what the last test was run
>>> an identify the issue. I didn't have exit, but I did have a test using
>>> backticks to restart a service I didn't have, which presumably caused the
>>> suit to exit.
>>>
>>> Thanks!
>>>
>>> On Friday, January 6, 2017 at 11:27:43 AM UTC-7, Myron Marston wrote:
>>>>
>>>> There are a variety of ways to filter specs, and one can imagine
>>>> configuring the filtering to be randomized to achieve the kind of behavior
>>>> you're seeing.  That said, you'd almost certainly have to set that up
>>>> intentionally to get that behavior and I can't imagine you're doing that.
>>>>
>>>> A more likely possibility is that you've got an `exit` or `exit!` call
>>>> somewhere in your spec suite or in code being called from your suite.  Such
>>>> a method call will cause the ruby interpreter to exit, cutting short the
>>>> run (at least on recent 3.x releases; we changed things to not interfere
>>>> with `exit` and `exit!` calls since they are core ruby methods we didn't
>>>> feel like we should interfere with).  My suggestion is to see what is the
>>>> last spec when your suite exits (running with `--format doc` will help
>>>> figure that out).  That spec is probably calling `exit` or calling code
>>>> that calls `exit`.  If you can find the `exit` call (or comment out the
>>>> spec) it will hopefully fix the problem.
>>>>
>>>> HTH,
>>>> Myron
>>>>
>>>> On Fri, Jan 6, 2017 at 10:19 AM, 'Dan Alvizu' via rspec <
>>>> rs...@googlegroups.com> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I recently upgraded an ancient rails 3.2 app to rails 4.1. Everything
>>>>> looks good, except my rspec doesn't want to run all tests now!
>>>>>
>>>>> If I run rspec --dry-run, I see 429 tests available. However I never
>>>>> see rspec actually run all of these tests. It runs what seems to be an
>>>>> indeterminate number of tests: sometimes as many as 237, sometimes as few
>>>>> as 2!
>>>>>
>>>>> I'm running rspec v 3.5.2-rails and rspec 3.5
>>>>>
>>>>> Is there any config or condition which would cause rspec to skip an
>>>>> entire test suite?
>>>>>
>>>>>
>>>>> --
>>>>> 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/edf89a5d-cc4f-4

Re: [rspec] rspec runs indeterminate number of tests

[Myron Marston]

Using backticks should spawn a subshell and run the provided command. I
didn’t think it could cause your current ruby process to exit. Can you
provide more detail about what was in the backticks? And can you see if it
was raising an exception (via a snippet like this)?

def safe_backticks(command)
  `#{command}`rescue Exception => ex
  puts "#{ex.class}: #{ex.message}"end

​

On Fri, Jan 6, 2017 at 10:48 AM, 'Dan Alvizu' via rspec <
rspec@googlegroups.com> wrote:

> Aha!
>
> Running with `--format doc` allowed me to see what the last test was run
> an identify the issue. I didn't have exit, but I did have a test using
> backticks to restart a service I didn't have, which presumably caused the
> suit to exit.
>
> Thanks!
>
> On Friday, January 6, 2017 at 11:27:43 AM UTC-7, Myron Marston wrote:
>>
>> There are a variety of ways to filter specs, and one can imagine
>> configuring the filtering to be randomized to achieve the kind of behavior
>> you're seeing.  That said, you'd almost certainly have to set that up
>> intentionally to get that behavior and I can't imagine you're doing that.
>>
>> A more likely possibility is that you've got an `exit` or `exit!` call
>> somewhere in your spec suite or in code being called from your suite.  Such
>> a method call will cause the ruby interpreter to exit, cutting short the
>> run (at least on recent 3.x releases; we changed things to not interfere
>> with `exit` and `exit!` calls since they are core ruby methods we didn't
>> feel like we should interfere with).  My suggestion is to see what is the
>> last spec when your suite exits (running with `--format doc` will help
>> figure that out).  That spec is probably calling `exit` or calling code
>> that calls `exit`.  If you can find the `exit` call (or comment out the
>> spec) it will hopefully fix the problem.
>>
>> HTH,
>> Myron
>>
>> On Fri, Jan 6, 2017 at 10:19 AM, 'Dan Alvizu' via rspec <
>> rs...@googlegroups.com> wrote:
>>
>>> Hi!
>>>
>>> I recently upgraded an ancient rails 3.2 app to rails 4.1. Everything
>>> looks good, except my rspec doesn't want to run all tests now!
>>>
>>> If I run rspec --dry-run, I see 429 tests available. However I never see
>>> rspec actually run all of these tests. It runs what seems to be an
>>> indeterminate number of tests: sometimes as many as 237, sometimes as few
>>> as 2!
>>>
>>> I'm running rspec v 3.5.2-rails and rspec 3.5
>>>
>>> Is there any config or condition which would cause rspec to skip an
>>> entire test suite?
>>>
>>>
>>> --
>>> 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/ms
>>> gid/rspec/edf89a5d-cc4f-4240-aa8b-20407f8cc8d4%40googlegroups.com
>>> <https://groups.google.com/d/msgid/rspec/edf89a5d-cc4f-4240-aa8b-20407f8cc8d4%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/cac38f21-2ef7-4609-9d71-d6316412f78b%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/cac38f21-2ef7-4609-9d71-d6316412f78b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsrSN4z6%2BfziT8F6ACYu5QTgRyWseG8i-8DmUqMsoD4aA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] rspec runs indeterminate number of tests

[Myron Marston]

There are a variety of ways to filter specs, and one can imagine
configuring the filtering to be randomized to achieve the kind of behavior
you're seeing.  That said, you'd almost certainly have to set that up
intentionally to get that behavior and I can't imagine you're doing that.

A more likely possibility is that you've got an `exit` or `exit!` call
somewhere in your spec suite or in code being called from your suite.  Such
a method call will cause the ruby interpreter to exit, cutting short the
run (at least on recent 3.x releases; we changed things to not interfere
with `exit` and `exit!` calls since they are core ruby methods we didn't
feel like we should interfere with).  My suggestion is to see what is the
last spec when your suite exits (running with `--format doc` will help
figure that out).  That spec is probably calling `exit` or calling code
that calls `exit`.  If you can find the `exit` call (or comment out the
spec) it will hopefully fix the problem.

HTH,
Myron

On Fri, Jan 6, 2017 at 10:19 AM, 'Dan Alvizu' via rspec <
rspec@googlegroups.com> wrote:

> Hi!
>
> I recently upgraded an ancient rails 3.2 app to rails 4.1. Everything
> looks good, except my rspec doesn't want to run all tests now!
>
> If I run rspec --dry-run, I see 429 tests available. However I never see
> rspec actually run all of these tests. It runs what seems to be an
> indeterminate number of tests: sometimes as many as 237, sometimes as few
> as 2!
>
> I'm running rspec v 3.5.2-rails and rspec 3.5
>
> Is there any config or condition which would cause rspec to skip an entire
> test suite?
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/edf89a5d-cc4f-4240-aa8b-20407f8cc8d4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmv7v6r%3Dh2Hp6P3Z%3DVdT4UCh%3DhYGpLdRqS2wD%2BhLZh-WUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] difference in rspec behavior when no arguments provided

[Myron Marston]

The only difference between rspec and rspec path/to/file is that rspec
loads all files matching the default pattern (spec/**/*_spec.rb) where as rspec
path/to/file loads only the specified file. I suspect that when you run rspec
path/to/file you might not be using bundler to manage and isolate your load
path, whereas raw rspec is probably booting rails and loading using
bundler. If watir is installed as a system gem but is not in your bundle
then this behavior would make sense.

HTH,
Myron
​

On Tue, Dec 20, 2016 at 2:55 PM, Artie  wrote:

> Hello!
>
> Maybe somebody with more experience can see what's up with the different
> invocations of rspec?
>
> I set up a new Rails app environment and noticed that when I run `rspec`
> alone on the command like I get a complaint from rails active_support:
>
>active_support/dependencies.rb cannot load such a file -- watir
> (LoadError)
>
> for which, in the traceback, line 3 of watir_smoketest_spec.rb is
> specified as the culprit:
> require 'watir'
>
> Yet, when I turn rspec with a argument:
>`rspec spec/features/watir_smoketest_spec.rb`
>
> Watir is found and browser windows start popping up, executing the code
> stored in 'spec/features/watir_smoketest_spec.rb'; which is the example
> Google search from the Watir home page.
>
> Why is there such a striking difference in behavior? What can I learn from
> this?
>
> What article/doc should I be reading? :)
>
> Thank you for reading and wanting to help.
>
> --az
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/1260462d-af2f-4fc9-9ef3-ef6579fac77f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmumUFMKz1jcd%3Dg1fkH0w%2Bt8rT0v%2BO3Pw5nKJk_Xp0kr7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] What does RSpec stand for?

[Myron Marston]

I'm not sure (I wasn't around when RSpec was first named) but I've always
thought the "R" stood for "Ruby", similar to the J in JUnit standing for
Java, N in NUnit standing for .NET, etc.

Myron

On Mon, Nov 7, 2016 at 1:58 AM, Panayotis Matsinopoulos <
panayo...@matsinopoulos.gr> wrote:

> Dear All,
>
> It may have been answered in the past...but I cannot find it.
>
> Does RSpec stand for "Requirements Specification"?
>
> Thanks in advance
> Panos M.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/3d9fe7d3-ac30-41db-aefd-7a19abbc4707%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmssdbu%2BGazLZpPfOiV6GB83djJd-o%3DqVb%3DcsiGK79pfLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: Rspec set-up for Windows 7

[Myron Marston]

I've never heard of windows users having to do that.  I thought rubygems
took care of installing executables in a way that would work on windows
without needing to explicitly call ruby.

That said, I last used Windows in 2008 so I really have no idea.  But I do
find it surprising.

On Wed, Oct 19, 2016 at 11:18 PM, Mr. Kennedy  wrote:

> Ah, I think I've got it... I just need to explicitly call ruby:
>
> ruby bin/rspec --format doc
>
> and the test gets run - YaY!
>
> After poking at my Environment Variable Path to make sure ruby.exe was in
> there (C:\Ruby22\bin) and looking at my Program Defaults - I thought that I
> could tell win7 to associate any file named "rspec" with ruby.exe (per
> https://support.microsoft.com/en-us/help/18539/windows-7-
> change-default-programs - I couldn't actually add file type "extensions"
> or "protocols" - I could only change them, but .rb and .rbw were in there!)
> it occurred to me that I just needed to tell ruby to ingest the command...
> Heh.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/5d7ff2f2-3be4-42ae-9a95-cb20bda58301%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvr_3fSDtOsFDbPczi9pQ_Woe-PODbSh0FvF%3D15Sj2ECA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Rspec.describe on windows 7 results in an error?

[Myron Marston]

What version of RSpec are you using?  Run `rspec -v` (or look in your
`Gemfile.lock` if you are using bundler) to find out.  If you're using
RSpec 3.x, I would absolutely expect `RSpec.describe` to work.  But on
RSpec 2.x it should not.  It was part of the move in 3.x to support a zero
monkey patching mode:

http://rspec.info/blog/2014/05/notable-changes-in-rspec-3/#new-exposedslglobally-config-option-to-disable-rspec-core-monkey-patching

HTH,
Myron

On Tue, Oct 18, 2016 at 10:54 PM, Mr. Kennedy  wrote:

> Hello, I just got Rspec configured on my win7 lappy after wrestling
> against RubyGems v2.4 (broken for Windows) and updating RubyGems to v2.6.7.
> I'm just going through the tutorial videos on the home page
> http://rspec.info/ and am wondering if it is just a Windows thing that
> "Rspec.describe" throws an error? E.g. the bowling example:
> require 'bowling'
>
> # Rspec.describe Bowling, "#score" do #<-- this throws an error
> describe Bowling, "#score" do  #<-- this works
>   context "with no strikes or spares" do
> it "sums the pin count for each roll" do
>   bowling = Bowling.new
>   20.times { bowling.hit(4) }
>   expect(bowling.score).to eq 80
> end
>   end
> end
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/2f62429d-3e21-4cc3-8b3a-2f83c210dc9a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvOkfdkqhw5d3joT0dtBGnXLykti5WTS4r2mDn-_fo7ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] best practice to tear down classes defined inside describe blocks

[Myron Marston]

My suggestion is to use anonymous classes declared in-line:

# ./spec/foo_spec.rbrequire 'spec_helper'

describe 'Foo' do
  let(:person_class) do
Class.new(ActiveRecord::Base) do
  has_many :abilities
end
  end

  it 'has relations' do
expect(person_class.reflections.keys).to eq %w(abilities)
  endend
# ./spec/bar_spec.rbrequire 'spec_helper'

describe 'Bar' do
  let(:person_class) do
Class.new(ActiveRecord::Base) do
  has_many :children
end
  end

  it 'has relations' do
expect(person_class.reflections.keys).to eq %w(children)
  endend

There are two nice things about this:

   - No cleanup is needed. Since the classes are anonymous, there are no
   constant references to them and once the example completes Ruby’s garbage
   collector will take care of it.
   - There’s no possibility of re-opening an existing class. Class.new
   *always* makes a new class.

The downside is that the class does not have a constant, which might not
play nice with activerecord (it may not support anonymous subclasses) and
it will be less pretty in error messages.

If you want to make it a named class, you can use RSpec’s constant
stubbing; it exists specifically for this:

# ./spec/foo_spec.rbrequire 'spec_helper'

describe 'Foo' do
  before do
stub_const("Person", Class.new(ActiveRecord::Base) do
  has_many :abilities
end)
  end

  it 'has relations' do
expect(Person.reflections.keys).to eq %w(abilities)
  endend
# ./spec/bar_spec.rbrequire 'spec_helper'

describe 'Bar' do
  before do
stub_const("Person", Class.new(ActiveRecord::Base) do
  has_many :children
end)
  end

  it 'has relations' do
expect(Person.reflections.keys).to eq %w(children)
  endend

RSpec will take care of cleaning up the Person constant created in each
example, ensuring the constants do not leak and cause problems.

HTH,
Myron

On Thu, Oct 13, 2016 at 2:49 AM, Jean-Michel Garnier <
jean-mic...@21croissants.com> wrote:

Hi,
>
> Not sure this is the best place, traffic seems quite low these days.
>
> I am wondering what is the best practice to tear down classes declared
> inside `describe` blocks.
> For example:
>
> ```ruby # ./spec/foo_spec.rb require 'spec_helper' describe 'Foo' do class
> Person < ActiveRecord::Base has_many :abilities end it 'has relations' do
> expect(Person.reflections.keys).to eq %w(abilities) end end #
> ./spec/bar_spec.rb require 'spec_helper' describe 'Bar' do class Person <
> ActiveRecord::Base has_many :children end it 'has relations' do
> expect(Person.reflections.keys).to eq %w(children) end end ```
>
> Running each individual file passes but when I run both files then it
> fails (in both files with `["children", "abilities"]` in relations array).
>
> To solve that problem, we use an `after(:all)` block to remove the
> constant with `Object.send(:remove_const, 'Person').
>
> I'd love to hear if other people use that tear down or what is the best
> practice.
>
> Thanks,
>
> JM
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/8e469a6b-1175-4299-bf99-c90ffd587ca6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
​

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmuG7KnUVkDDwFgpv3i8bsuKE_rcsxNN9r8v9seRJyHr5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[rspec] Re: Verifying Context

[Myron Marston]

In general, yes, I've also found it useful to express pre-conditions as 
expectations in some situations.  I usually do this when I've realized that 
the test I'm writing has a non-obvious assumption that, if it was ever 
violated due to a config change or some other change, would cause the test 
to pass without exercising the code I intend it to.  You don't want a 
future change to cause a test to start passing only because it's no longer 
exercising the logic it is intended to cover.

That said, in the example you gave, it's not clear to me what the value is. 
 Are you concerned that `build` might one day change to no longer return a 
Hash?

HTH,
Myron

On Friday, September 2, 2016 at 5:25:46 AM UTC-7, Panayotis Matsinopoulos 
wrote:
>
> Hi,
>
> I would like to have your opinion on the following.
>
> I have found very useful to verify the context of an example. What do I 
> mean? See the following example:
>
> describe MyClass do
>   describe '#process' do
> context 'when something is a Hash' do
>let(:something) { build(:something) }
>
>before do
>   expect(something).to be_a(Hash)
>end
>
>it 'returns an open struct' do
>  expect(subject.process(something)).to be_a(OpenStruct)
>end
> end
>   end
> end
>
> Do you see that in the before block I am verifying that the context of the 
> "it" is correct?
>
> To me, this has been proven very useful. Because sometimes, the context 
> setup code might not be doing what we are expecting it to do. The 
> verification code does the double check.
>
> What is your opinion about this practice? Is this a practice that you 
> apply too? Or am I overprotective?
>
> Panos
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/19b746ee-acec-4c99-9dc6-b87d43aa896d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Running Rspec on Rake task

[Myron Marston]

Something like this should work:

https://gist.github.com/myronmarston/37b74e2551007dee75a21a79cc3d5a9c


HTH,
Myron


On Tue, Aug 16, 2016 at 9:32 AM, Jordano Moscoso 
wrote:

> Is there any way to run all my tests on a rake task?
>
> task :runtests=> :environment do
> **HERE RUN RSPEC WITH ALL TESTS AND GET THE RESULT TO A STRING**
> THEN DO SOMETHING WITH TE RESULT
> end
>
> Thanks.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/d69addeb-957d-4dec-b34a-b2cf9696863d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmuirFh3ehnCbtg_hpBVTdEjELNBjUftLf23n0ZUay9EMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Nested database transactions to speed up the test suite

[Myron Marston]

Cool!  Thanks for sharing, Rodrigo.

On Sun, Aug 7, 2016 at 10:45 AM, Rodrigo Rosenfeld Rosas  wrote:

> Hi, maybe some of you might be interested in the approach I described in
> the following article [1] suggesting to use nested database transactions to
> speed up a test suite by creating common records in a before(:all) block
> rather than recreating them before every single test in the group. To make
> things simpler, I've also released the rspec_nested_transactions gem [2].
> There are examples demonstrating how easy it is with both Sequel and
> ActiveRecord, provided your database supports either nested transactions or
> savepoints:
>
> http://rosenfeld.herokuapp.com/en/articles/ruby-rails/
> 2016-08-05-using-rspec-nested-transactions-to-speed-up-
> tests-touching-the-database
>
> https://github.com/rosenfeld/rspec_nested_transactions
>
> I hope it could be useful to some of you.
>
> Thanks, Myron, for the idea to use Ruby Fibers to implement an
> around(:all)-like block in RSpec, a few years ago :) That was a really
> clever trick :)
>
> Cheers,
> Rodrigo.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/rspec/fcd8faf0-a9be-4ed0-b680-f38861feda6f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvEXnQRRg-HVYtjC%3DSB%3Dd7FArBmnB%3DGFqQka6q6wv0VdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] ArgumentError only within rspec test

[Myron Marston]

Ah, I see what's happening.  Because you've defined a file at
`lib/cinch/user.rb` and `lib` is on the load path, it means that a `require
'cinch/user'` from anywhere will load your file instead of the file in the
gem.

One solution is to remove `lib` from the load path.  RSpec does not expose
an API to prevent it from adding `lib`, but you can manually remove it from
`$LOAD_PATH` by putting logic in `spec/spec_helper.rb` (or similar) to do
that.  `$LOAD_PATH` is a ruby array so you can modify it however you like
from anywhere in your program.

That said, I wouldn't recommend that solution.  RSpec puts `lib` on the
load path for a reason -- that's the standard environment ruby code usually
runs in.  For example, if you have a gem, rubygems will put your `lib`
directory on the load path.  I thought that Rails also put `lib` on the
load path but I might be wrong about that given I haven't used rails in 5+
years.  Remove `lib` from the load path will solve your immediate problem
but I think it papers over the problem and the problem might resurface when
you run your code in other environments.

Instead, I recommend you avoid putting any of your logic in files named
`lib/cinch/*`.  The `cinch` namespace is owned by the gem and if any of
your code defined in a directory named `lib/cinch` is prone to having these
sorts of issues.  Instead, I recommend renaming your directory to
`lib/cinch_extensions` or `lib/my_app/cinch` or similar.  Then there's no
risk of requires not working properly.

HTH,
Myron

On Sun, Jul 24, 2016 at 12:25 PM, Jonas Osborn 
wrote:

> Thanks for the response.
> Incidentally I did have more to add in my first post but being new to
> Google group pressed tab and enter accidentally and suddenly it was gone...
> It is as you say, its to do with a conflicting ::User. The trouble is I
> have a Cinch::User in my code that when I run my application, re-opens the
> User class and adds some methods. But when I run 'rspec', the Cinch::User
> class is not re-opened, somehow it overwrites all of Cinch::User (thus the
> problem with initialize).
> I googled around a bit and apparently it is because rspec automatically
> adds the local lib folder to $LOAD_PATH. So running 'ruby -Ispec
> -rrspec/autorun path/to/spec.rb' (i.e. omitting the -Ilib flag) encounters
> no problems.
> Is there a way I can either not automatically add lib to $LOAD_PATH when
> running rspec?
> or is running 'rspec' not important and should I just always run the ruby
> command?
> or is there a different way I could re-open Cinch::User without it being
> overwritten when 'rspec'-ing?
> or any other solution?
> I could also move my code out of lib but although I am new it is my
> impression that that is where the code should be.
> Cheers,
> Jonas
>
> On Sunday, 24 July 2016 19:47:36 UTC+1, Myron Marston wrote:
>>
>> Based on your stack trace, the problem appears to originate from this
>> line of code:
>>
>> https://github.com/cinchrb/cinch/blob/v2.3.2/lib/cinch/bot.rb#L354
>>
>> Notice that it is calling `super(nil, self)`. It's passing 2 arguments up
>> to the superclass's `initialize` method but the superclass's definition
>> does not accept any arguments, so Ruby is giving you an error, indicating 2
>> args were passed but 0 are accepted.
>>
>> That class is subclassing `User` (presumably, `Cinch::User`, given it is
>> defined within the `Cinch` module).  `Cinch::User` accepts a variable
>> number of arguments:
>>
>> https://github.com/cinchrb/cinch/blob/v2.3.2/lib/cinch/user.rb#L190
>>
>> <https://github.com/cinchrb/cinch/blob/v2.3.2/lib/cinch/user.rb#L190>
>> So it's quite strange you're getting the error.  My best guess is that
>> `User` is perhaps being resolved to `::User` (e.g. your application's User
>> class) instead of `Cinch::User`, but that should  only happen if
>> `Cinch::User` is not defined -- and it certainly is being required at the
>> top of `cinch/bot.rb`.
>>
>> I don't think there's any way RSpec can directly be causing this, but
>> there is probably something different about the environment the code is
>> running in via RSpec vs IRB.  You might be able to figure it out by
>> printing `$LOAD_PATH` and `$LOADED_FEATURES` to see the differences in load
>> path and what files have been loaded in the two environments.
>>
>> I'd also suggest you check with the maintainers of the cinch library.
>> Something weird is going on in it.
>>
>> HTH,
>> Myron
>>
>>
>>
>> On Sun, Jul 24, 2016 at 9:09 AM, Jonas Osborn 
>> wrote:
>>
>>> Hi
>>> I am very new to 

Re: [rspec] ArgumentError only within rspec test

[Myron Marston]

Based on your stack trace, the problem appears to originate from this line
of code:

https://github.com/cinchrb/cinch/blob/v2.3.2/lib/cinch/bot.rb#L354

Notice that it is calling `super(nil, self)`. It's passing 2 arguments up
to the superclass's `initialize` method but the superclass's definition
does not accept any arguments, so Ruby is giving you an error, indicating 2
args were passed but 0 are accepted.

That class is subclassing `User` (presumably, `Cinch::User`, given it is
defined within the `Cinch` module).  `Cinch::User` accepts a variable
number of arguments:

https://github.com/cinchrb/cinch/blob/v2.3.2/lib/cinch/user.rb#L190


So it's quite strange you're getting the error.  My best guess is that
`User` is perhaps being resolved to `::User` (e.g. your application's User
class) instead of `Cinch::User`, but that should  only happen if
`Cinch::User` is not defined -- and it certainly is being required at the
top of `cinch/bot.rb`.

I don't think there's any way RSpec can directly be causing this, but there
is probably something different about the environment the code is running
in via RSpec vs IRB.  You might be able to figure it out by printing
`$LOAD_PATH` and `$LOADED_FEATURES` to see the differences in load path and
what files have been loaded in the two environments.

I'd also suggest you check with the maintainers of the cinch library.
Something weird is going on in it.

HTH,
Myron



On Sun, Jul 24, 2016 at 9:09 AM, Jonas Osborn 
wrote:

> Hi
> I am very new to ruby and rspec so apologies if this is a stupid question,
> but I'm trying to start using rspec and am getting an error that is
> confusing me. I have a spec that fails on an ArgumentError, the confusing
> thing for me is running the same thing in a interactive ruby shell or my
> script doesn't give an ArgumentError. So while I would normally think this
> was a problem with the gem I am using or how I am using it, the fact that I
> was having no problems until I tried to use rspec is making me wonder if I
> have missed something about rspec. Anyway here is my spec file:
> require "cinch"
>
> describe "Cinchbot" do
>   it "why does this not work" do
>
>  Failure/Error: Cinch::Bot.new
>
>  ArgumentError:
>wrong number of arguments (2 for 0)
>  #
> /usr/local/rvm/gems/ruby-2.2.4/gems/cinch-2.3.2/lib/cinch/bot.rb:354:in
> `initialize'
>  #
> /usr/local/rvm/gems/ruby-2.2.4/gems/cinch-2.3.2/lib/cinch/bot.rb:354:in
> `initialize'
>  # ./spec/bot/bot_spec.rb:5:in `new'
>  # ./spec/bot/bot_spec.rb:5:in `block (2 levels) in '
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/913967f7-9e85-4087-a393-e2a4d1cf397c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvTdEw3KqmPprcdSVXTupZ9fd%3Dne4mUOYja%2Bo6HuTY3SQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Custom execution order for tests in rspec

[Myron Marston]

We don't support the ability to pause a spec and allow another one to
proceed, then later resume the spec.  It goes against some of the main
principles that guided the design of RSpec such as test independence and
isolation.

Sorry :(.

Myron

On Wed, Jul 20, 2016 at 4:57 AM, Aravindh Sridharan 
wrote:

> Hi, I am currently having a issue with respect to execution order of tests
> in our rspec suite. Our application is big data pipeline where the front
> facing server (collector) accepts requests and sends the data to other
> components for transformation. So the collector responds with 202 status
> rather than 200. After few seconds the data is available for querying. The
> Querying server (QueryAPI) responds to certain queries on the data. In
> order to test this, I have to put data into collector, wait for sometime
> and query the QueryAPI and assert the result. I didnt want to repeat this
> process for every test as sleeping for every test is time consuming. So
> currently the tests are like put all the data required to the collector in
> before block and at the end of before block, wait for sometime and then the
> "it" block will call QueryAPI and assert. This seems ugly as it is
> difficult for me to map the test data with the test. Is there a way to
> create two custom blocks viz. ingest" bock & "query" block inside "it"
> block and then run all ingest blocks together, wait for sometime and run
> query blocks. This will help in readability of the tests. Below is an
> example of what i want
>
>
>
> describe "Test" do
>   it "Test 1" do
> ingest "collector" do
>   #input data here
> end
> query "queryapi" do
>   assert result here
> end
>   end
>   it "Test 2" do
> ingest "collector" do
>   #input data here
> end
> query "queryapi" do
>   assert result here
> end
>   end
> end
>
> The ingest blocks of two tests should run first, wait for sometime and
> then run the query blocks. Is this possible?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/e9891215-7c49-4b73-9de4-24979e3058f3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmteRrAFJGSt4UcN3V-UpsFz8ZkNiy-AV5Uj1v39r8nQxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] spec isolation when using 3rd party gems

[Myron Marston]

I would not use a test double for BCrypt in this case.  Generally we
recommend only mocking interfaces you own, and you don't own the BCrypt
interface.  In addition, AFAIK, the BCrypt provides a pure,
side-effect-free and I/O-free interface, so I don't see how using a test
double benefits you -- in this situation it looks like it just tightly
couples your test to the BCrypt interface (making your test more brittle)
and makes your test less realistic (providing no confidence it'll work w/o
the test double).

However, if you wanted to provide an abstraction over BCrypt (e.g. to
support swapping out hashing implementations in a single spot), it would
make sense to use a test double in place of your own abstraction.

For the user, I would not necessarily use a test double unless `User` was a
heavy dependency.  If it's just a light-weight struct or similar object,
I'd just use the real thing.  If you do use the test double, we recommend
you use `instance_double("User")` so as to get interface verification.

HTH,
Myron

On Fri, Jun 3, 2016 at 8:37 AM, 'Andy' via rspec 
wrote:

> Hi,
>
> I've been trying out rspec recently and I've also been trying to test in
> isolation more but I'm unsure how to approach specs for code that leverages
> 3rd parties.
>
> Take this over simplified example:
>
> class UserAuthenticator
>   def initialize(user)
> @user = user
>   end
>
>   def authenticate_by_password(clear_password)
> @user if BCrypt::Password.new(@user.hashed_password) == clear_password
>   end
> end
>
> In the test you could use a double for the user like this (I'm assuming
> this is the correct thing to do)
>
> it 'returns a user if password is correct' do
>   user= double('User', hashed_password:"precomputed hash of 'pass'")
>   expect(UserAuthenticator.new(user).authenticate_by_password('pass')).to
> eql(user)
> end
>
> Would you leave it at that in this case? Or should Bcrypt be
> stubbed/mocked as well? Or should the password check using BCrypt be in
> it's own class/method (PasswordChecker)?
>
> I guess I'm really interested at what point you would draw the line when
> it comes to isolating specs because it seems like trying to be a purist and
> isolate all external classes/methods leads to diminishing returns at some
> point.
>
> Thanks.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/79d4a610-f034-4c27-b018-84c8a6bbf619%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmv6__m7GmSo6RytqwjGCnUXEk9t31cUptF1Jdms8f39fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Deprecating controller specs?

[Myron Marston]

Xavier: I believe Stefan is talking about this talk from Justin Searls from
rails conf:

http://blog.testdouble.com/posts/2016-05-09-make-ruby-great-again.html

On Sat, May 14, 2016 at 10:09 AM, Xavier Shay  wrote:

> which talk?
>
>
> On Sat, May 14, 2016, at 09:54 AM, Stefan Kanev wrote:
>
> Hi everybody.
>
> I recently watched a talk that said controller specs are getting
> deprecated in the next version of RSpec. I found that surprising. I’m
> definitely not trying to push against this decision, but I would really
> like to understand its logic.
>
> I’ve thought long and hard and I was not able to convince myself that
> controller specs are unhelpful. Of course, in order to be useful, they
> require a certain style of writing specs and controllers. I’d like to
> explain my approach and I’d really love to get some feedback. Am I missing
> something that invalidates my logic?
>
> Let’s start with “my” style of controllers. They should contain as little
> logic as possible and delegate everything else to collaborators (a model or
> a service). Each controller essentially follows the same pattern:
>
>1. It picks a bunch of stuff from params
>2. It passes them to a model/service that carries out the work
>3. It decides what to do next based on the outcome (render a template
>or redirect somewhere)
>
> The create action in the default scaffold are a great example. To
> summarise, a controller:
>
>- delegates (most of) the work to a model/service;
>- is responsible for figuring out what to pass to the model/service;
>- is responsible for deciding where to send the user next;
>- usually communicates with a single model/service over a thin (1-2
>methods) interface;
>- uses a small number (1-2) of instance variables to pass to the view.
>
> Now, following this style, the spec is written like so:
>
>- Collaborators are replaced with doubles
>- Just to be clear, the database isn’t hit, neither in setup nor
>verification
>- Views are not rendered
>- Expectations are set on (1) messages sent to collaborators, (2) the
>HTTP response (redirect, render, etc) and (3) variables passed to the view.
>
> As far as I can tell, this is the GOOS style of testing, applied to
> controllers – collaborators are mocked and the interaction itself is
> tested, not the end result. If memory serves right, that’s also how The
> RSpec Book talks about controller specs. If you want an example, you can
> check this controller
> 
> and this spec
> 
> I wrote a while ago.
>
> I’m under the impression that this is the popular style of controller
> specs in the RSpec community, although I might be wrong. I’m reiterating it
> only to make sure we’re on the same page.
>
> So, anyway: assuming controller specs are written that way, I think they
> are indeed useful. Just not in the same way as feature or model specs.
>
> The point of view I subscribe to, is that automated testing is not just
> about catching regressions (Safety Net). It’s about many things, like
> documentation, driving design, productivity, to name a few. Yes, the Safety
> Net of controller specs is nowhere near what you get out of feature or
> request specs. But that’s not why I write controller specs. I write them
> because they help design. Namely, the spec:
>
>- gives feedback that helps keep the interface between controller and
>collaborator simple;
>- puts positive pressure on the design direction – another developer
>is less likely to extend the controller with the business logic and more
>likely to put in the service;
>- helps move the logic away from the controller to a model/service,
>where it can be tested in isolation and relatively faster (compared to
>request/feature).
>
> I admit that when I was starting, this was a tricky concept to get right.
> But once I grokked it, it was pivotal to my understanding of how to keep
> the controller simple. Controller specs have helped me learn how to do
> better design and they keep helping me to keep my designs clean.
>
> It goes without saying, but I also write feature specs that also cover
> (some of) the logic in integration.
>
> So, conclusion time. If you’ve gone this far into reading this, I thank
> you for your time, and I would really like to hear what you think.
>
> To loop back to the beginning, controller specs are getting deprecated.
> Justin suggests using request specs instead. I neither feel that I will
> benefit from stopping, nor I see how replacing them with request specs is
> better. Hence, I don’t understand the decision to deprecate controller
> specs.
>
> What am I missing?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "rspec" group.
> To unsubscribe from this group and sto

Re: [rspec] Deprecating controller specs?

[Myron Marston]

Great questions, Stefan!

Let me preface my answer by saying: I’m not a rails user (and haven’t been
for ~5 years) so my understanding of the situation may not be quite
correct. Sam Phippen, Jon Rowe, or Aaron Kromer should be able to give you
a more definitive answer but I’ll weigh in anyway.

The TL;DR is that the RSpec team has not chosen to deprecate controller
specs — the Rails team has. Controller specs in rspec-rails wrap the rails
controller functional testing infrastructure. The Rails team has chosen to
remove this from Rails 5 — which means rspec-rails simply can’t support
controller specs with Rails 5 out-of-the-box.

Luckily, the rails team has moved the controller testing bits into the rails
controller testing  gem,
and writing controller specs with Rails 5 (and RSpec 3.5) should work if
you add that gem to your Gemfile.

As for the whether or not controller specs are a good idea: as with all
things, it depends. Historically, Rails has had 2 similar (but slightly
different) kinds of tests, and rspec-rails followed suit:

   - Controller specs
   - Request specs

They look vaguely similar and the guidelines of when to use one vs the
other is not very clear. Both allow you to simulate requests and make
assertions about responses. The main difference is that controller specs
instantiate your controller class and call methods on it directly
(bypassing the routing layer and rack middleware stack) whereas request
specs go through routing and rack middleware. This has a couple notable
effects:

   - Controller specs were noticeably faster since they did so much less
   - Controller specs are full of gotchas, where something that a user
   would expect to work would not work because to work properly the request
   needs to go through one or more rack middlewares. In general, Rails
   controllers are designed to interact with rack middleware for all sorts of
   things so when you eliminate the middleware, the results can be strange and
   unintuitive. We’ve had many bug reports on rspec-rails that basically
   boiled down to “that’s just how controller specs work, so use a request
   spec instead for what you are trying to test.”

>From what I understand, the Rails team has worked on making the full
request specs faster in Rails 5 so that they are basically at speed parity
with old controller specs. This means that the main benefit of controller
specs over request specs (speed) no longer exists. Thus, the recommendation
of the rails core team is to not write controller tests anymore, and write
request tests instead.

In general, that’s sound advice. For a specific project, controller specs
might still make sense if you are really looking for the kind of isolation
controller specs give you and understand the gotchas.

I haven’t done Rails in a long time, but if I was — I’d generally try to
keep my controllers free of much logic (delegating requests to bare ruby
classes that can easily be tested in isolation) which means I’d tend to
favor request specs as a way to ensure things work end-to-end and bypass
controller specs altogether. On your project that may not be sound advice,
though.

HTH,
Myron

On Sat, May 14, 2016 at 9:54 AM, Stefan Kanev 
wrote:

Hi everybody.
>
> I recently watched a talk that said controller specs are getting
> deprecated in the next version of RSpec. I found that surprising. I’m
> definitely not trying to push against this decision, but I would really
> like to understand its logic.
>
> I’ve thought long and hard and I was not able to convince myself that
> controller specs are unhelpful. Of course, in order to be useful, they
> require a certain style of writing specs and controllers. I’d like to
> explain my approach and I’d really love to get some feedback. Am I missing
> something that invalidates my logic?
>
> Let’s start with “my” style of controllers. They should contain as little
> logic as possible and delegate everything else to collaborators (a model or
> a service). Each controller essentially follows the same pattern:
>
>1. It picks a bunch of stuff from params
>2. It passes them to a model/service that carries out the work
>3. It decides what to do next based on the outcome (render a template
>or redirect somewhere)
>
> The create action in the default scaffold are a great example. To
> summarise, a controller:
>
>- delegates (most of) the work to a model/service;
>- is responsible for figuring out what to pass to the model/service;
>- is responsible for deciding where to send the user next;
>- usually communicates with a single model/service over a thin (1-2
>methods) interface;
>- uses a small number (1-2) of instance variables to pass to the view.
>
> Now, following this style, the spec is written like so:
>
>- Collaborators are replaced with doubles
>- Just to be clear, the database isn’t hit, neither in setup nor
>verification
>- Views are not rendered
> 

Re: [rspec] understanding RSpec's design

[Myron Marston]

To expand on what Jon said: we offer random ordering as a way to surface
accidental ordering dependencies.  It's not possible to offer random
ordering if the specs are executed as they are defined, because the order
they are defined is the same on every run of the suite.

On Mon, Apr 25, 2016 at 4:36 PM, Jon Rowe  wrote:

> The “alternative” strategy you suggest isn’t really possible for us, but
> in it wouldn’t allow any kind of ordering other than “defined"
>
> Jon Rowe
> ---
> m...@jonrowe.co.uk
> jonrowe.co.uk
>
> On Tuesday, 26 April 2016 at 09:30, bonesk...@boneskull.com wrote:
>
> Sorry, I think my reading comprehension was poor, as it seems you did
> answer this indirectly.
>
> OK, it looks like the "why" would then be to offer ordering and filtering
> functionality.  Is this correct?
>
> I would assume (remember, *I'm* not expecting different behavior; some
> users are) the "alternative" would be that a test is executed *when it's
> encountered, *as opposed to "collecting" all the suites (or "groups",
> "describes", etc.) beforehand, then choosing which tests (or "specs",
> "examples", etc.) to run (and in what order).
>
> I'm going to guess that the "inclusion" filtering is not possible without
> using the current strategy, because the "alternative" strategy would not
> necessarily know that an "inclusion" filter was in use--until it was too
> late.
>
> How would the "alternative" strategy inhibit RSpec's ordering
> functionality, if at all?
>
> Thanks for helping me out.
>
> Chris
>
> On Monday, April 25, 2016 at 12:03:06 PM UTC-7, Myron Marston wrote:
>
> I tried to answer the "why" when I said:
>
> ...but for RSpec, we intentionally load all the specs first (which
> involves evaluating the `describe` blocks), then apply spec ordering,
> filtering, etc, and then run the specs (the `it` blocks).  Thus, the `3` is
> printed first (as it got printed while specs were being defined) and then
> the specs ran and 1 and 2 are printed.
>
>
> If that doesn't answer your question, can you explain what order you would
> expect?  The order RSpec operates in feels completely natural to me as it
> enables features like spec ordering, filtering, etc...but I've never really
> considered another ordering, so I'm not sure what order you have in mind
> that you are contrasting RSpec's ordering to.
>
> Myron
>
> On Mon, Apr 25, 2016 at 11:51 AM,  wrote:
>
> Gah, I screwed that up.  No, Mocha works like how you're describing; 3 1 2
> would be the order.
>
> So, now that I've confirmed it works the same, my answer is "why"?
>
>
> On Thursday, April 21, 2016 at 10:12:58 AM UTC-7, Myron Marston wrote:
>
> Assuming I understand your pseudocode correctly, your example would be
> written like this:
>
> ``` ruby
> RSpec.describe "foo" do
>   it "bar" do
> puts 1
>   end
>
>   describe "baz" do
> it "quux" do
>   puts 2
> end
>
> puts 3
>   end
> end
> ```
>
> This would print the numbers in the following order:
>
> 3
> 1
> 2
>
> ...which, noticably, is different from the order of mocha.  I can't
> comment on Mocha's design (having never used it) but for RSpec, we
> intentionally load all the specs first (which involves evaluating the
> `describe` blocks), then apply spec ordering, filtering, etc, and then run
> the specs (the `it` blocks).  Thus, the `3` is printed first (as it got
> printed while specs were being defined) and then the specs ran and 1 and 2
> are printed.
>
> HTH,
> Myron
>
> On Thu, Apr 21, 2016 at 9:50 AM,  wrote:
>
> Hi,
>
> I'm a current maintainer of Mocha <https://mochajs.org>, which (AFAIK)
> was inspired by RSpec.  I am not the *author *of Mocha; the author is
> long gone, or I'd ask him about this.
>
> My question regards a paradigm which seems common to BDD-style test
> frameworks.  I assume that RSpec works similarly, but I apologize if I'm
> incorrect.
>
> It's most easily illustrated with a pseudocode example (sorry, I'm
> unfamiliar with Ruby):
>
> begin suite 'foo'
>
>   begin test 'bar'
> print 1
>   end test
>
>   begin suite 'baz'
>
> begin test 'quux'
>   print 2
> end test
>
> print 3
>
>   end suite
> end suite
>
>
> In Mocha (and I assume RSpec), the following would be printed:
>
> 1
> 3
> 2
>
>
> This i

Re: [rspec] understanding RSpec's design

[Myron Marston]

I tried to answer the "why" when I said:

...but for RSpec, we intentionally load all the specs first (which involves
> evaluating the `describe` blocks), then apply spec ordering, filtering,
> etc, and then run the specs (the `it` blocks).  Thus, the `3` is printed
> first (as it got printed while specs were being defined) and then the specs
> ran and 1 and 2 are printed.


If that doesn't answer your question, can you explain what order you would
expect?  The order RSpec operates in feels completely natural to me as it
enables features like spec ordering, filtering, etc...but I've never really
considered another ordering, so I'm not sure what order you have in mind
that you are contrasting RSpec's ordering to.

Myron

On Mon, Apr 25, 2016 at 11:51 AM,  wrote:

> Gah, I screwed that up.  No, Mocha works like how you're describing; 3 1 2
> would be the order.
>
> So, now that I've confirmed it works the same, my answer is "why"?
>
>
> On Thursday, April 21, 2016 at 10:12:58 AM UTC-7, Myron Marston wrote:
>>
>> Assuming I understand your pseudocode correctly, your example would be
>> written like this:
>>
>> ``` ruby
>> RSpec.describe "foo" do
>>   it "bar" do
>> puts 1
>>   end
>>
>>   describe "baz" do
>> it "quux" do
>>   puts 2
>> end
>>
>> puts 3
>>   end
>> end
>> ```
>>
>> This would print the numbers in the following order:
>>
>> 3
>> 1
>> 2
>>
>> ...which, noticably, is different from the order of mocha.  I can't
>> comment on Mocha's design (having never used it) but for RSpec, we
>> intentionally load all the specs first (which involves evaluating the
>> `describe` blocks), then apply spec ordering, filtering, etc, and then run
>> the specs (the `it` blocks).  Thus, the `3` is printed first (as it got
>> printed while specs were being defined) and then the specs ran and 1 and 2
>> are printed.
>>
>> HTH,
>> Myron
>>
>> On Thu, Apr 21, 2016 at 9:50 AM,  wrote:
>>
>>> Hi,
>>>
>>> I'm a current maintainer of Mocha <https://mochajs.org>, which (AFAIK)
>>> was inspired by RSpec.  I am not the *author *of Mocha; the author is
>>> long gone, or I'd ask him about this.
>>>
>>> My question regards a paradigm which seems common to BDD-style test
>>> frameworks.  I assume that RSpec works similarly, but I apologize if I'm
>>> incorrect.
>>>
>>> It's most easily illustrated with a pseudocode example (sorry, I'm
>>> unfamiliar with Ruby):
>>>
>>> begin suite 'foo'
>>>
>>>   begin test 'bar'
>>> print 1
>>>   end test
>>>
>>>   begin suite 'baz'
>>>
>>> begin test 'quux'
>>>   print 2
>>> end test
>>>
>>> print 3
>>>
>>>   end suite
>>> end suite
>>>
>>>
>>> In Mocha (and I assume RSpec), the following would be printed:
>>>
>>> 1
>>> 3
>>> 2
>>>
>>>
>>> This is difficult for some users to reason about.  I'm unable to explain
>>> what this algorithm buys us, other than perhaps better control over
>>> disabling tests and suites.  Can anyone explain why it works as it does?
>>>
>>> thanks
>>> Chris
>>>
>>> --
>>> 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/872f0ecb-4ca1-4440-bb3f-27e111c80d89%40googlegroups.com
>>> <https://groups.google.com/d/msgid/rspec/872f0ecb-4ca1-4440-bb3f-27e111c80d89%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/cdfe4dcd-aea0-43ef-84fe-64603aa2c64f%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/cdfe4dcd-aea0-43ef-84fe-64603aa2c64f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsz1%3DzSgfKfVYcdFbNtVCZtMNCFTpvzGjrwdT8Tie9tew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] understanding RSpec's design

[Myron Marston]

Assuming I understand your pseudocode correctly, your example would be
written like this:

``` ruby
RSpec.describe "foo" do
  it "bar" do
puts 1
  end

  describe "baz" do
it "quux" do
  puts 2
end

puts 3
  end
end
```

This would print the numbers in the following order:

3
1
2

...which, noticably, is different from the order of mocha.  I can't comment
on Mocha's design (having never used it) but for RSpec, we intentionally
load all the specs first (which involves evaluating the `describe` blocks),
then apply spec ordering, filtering, etc, and then run the specs (the `it`
blocks).  Thus, the `3` is printed first (as it got printed while specs
were being defined) and then the specs ran and 1 and 2 are printed.

HTH,
Myron

On Thu, Apr 21, 2016 at 9:50 AM,  wrote:

> Hi,
>
> I'm a current maintainer of Mocha , which (AFAIK)
> was inspired by RSpec.  I am not the *author *of Mocha; the author is
> long gone, or I'd ask him about this.
>
> My question regards a paradigm which seems common to BDD-style test
> frameworks.  I assume that RSpec works similarly, but I apologize if I'm
> incorrect.
>
> It's most easily illustrated with a pseudocode example (sorry, I'm
> unfamiliar with Ruby):
>
> begin suite 'foo'
>
>   begin test 'bar'
> print 1
>   end test
>
>   begin suite 'baz'
>
> begin test 'quux'
>   print 2
> end test
>
> print 3
>
>   end suite
> end suite
>
>
> In Mocha (and I assume RSpec), the following would be printed:
>
> 1
> 3
> 2
>
>
> This is difficult for some users to reason about.  I'm unable to explain
> what this algorithm buys us, other than perhaps better control over
> disabling tests and suites.  Can anyone explain why it works as it does?
>
> thanks
> Chris
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/872f0ecb-4ca1-4440-bb3f-27e111c80d89%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQms-A_juG3T-An5oh0h1OTPQZ4dF%2BRF25ZXJ7SiA5JGaBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] "conditionally pending examples" in rspec 3.x?

[Myron Marston]

On RSpec 3 it’s far simpler:

pending if verifying_fixed?
find('#submit_button').value.should == 'RailsGoat h4x0r3d'

I believe transpec helps with this kind of thing. Have you tried following
our upgrade guide?

http://rspec.info/upgrading-from-rspec-2/
​


On Thu, Apr 14, 2016 at 2:04 PM, Al  wrote:

> I work on the OWASP Railsgoat project that is stuck at rspec 2.99.0 since
> "conditionally pending examples" were removed and
> 
> they are functional to the project.
> Here
> is an example
>
>  * pending(:if => verifying_fixed?) { find('#submit_button').value.should
> == 'RailsGoat h4x0r3d' }
>
> You can see the code on GitHub at https://github.com/OWASP/railsgoat .
> How do I make it 3.x compatible?
>
> I know that "should" format will need to be upgraded to "expect" format.
>
> Thanks,
> Al
>
>
> 
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/4a2f66a7-367b-4277-a8c1-8bead38a6ad1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQms%2BXTP7PzPEHp2j55Hg9%2B2AJTt3%3DZ8P2WO%2B9th2b%2Bbx%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: How to pass options to rspec when run via autorun? Or, have rspec read from stdin?

[Myron Marston]

Thanks for letting us know what you figured out, Robb!

On Fri, Mar 18, 2016 at 7:45 PM, Robb Shecter  wrote:

> Ah hah, Ruby does support the - parameter, although it's not document in
> the -h output. Therefore, this works and satisfies my two requirements:
>
>
> *$ cat example_spec.rb | ruby -rrspec/autorun - --format json*
>
>
>
> I.e., I can run RSpec on standard input, while setting options.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/b57d8d09-cb80-486c-a624-162e0568b9ef%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsH6kCFz_GUb8YHAqJLVAEC6netcc4XzB8jpG2KRatwqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Rspec with warnings - ignore gems / whitelist directories

[Myron Marston]

>
> How would you propose starting?


I'd start by writing a gem that isn't RSpec specific.  Write a gem that can 
be loaded in any ruby program and configured to silence some warnings and 
allow others.  Then the gem is useful outside an RSpec context.  You can 
always include a small RSpec shim that integrates the gem with RSpec for 
convenience for RSpec users.

On Saturday, February 27, 2016 at 5:42:57 PM UTC-8, Patrick Davey wrote:
>
>
> Another thing to bear in mind is that RSpec's `--warnings` flag is only 
>> intended to enable Ruby's warning mode -- which is an entirely different 
>> thing from warnings emitted by ruby code calling `$stderr.warn` but which 
>> is surfaced to the user in the same way (via $stderr).  It's not totally 
>> clear to me what kind of warnings you're intending to solve, Patrick.
>>
>  
>
> Heh, I'm not exactly sure either Myron ;) which may be an issue! Basically 
> I just turned on rpsec's --warnings flag and was inundated with messages 
> from other people's gems, and my first thought was that I'd like to be able 
> to only see warnings which have been raised for code that I have written. 
> That was the use case I was trying to fix.
>
>  
>
>> Personally, I wish Ruby itself provided APIs to control warnings more 
>> tightly so that you could enable it for only particular files or 
>> directories.  Such an API could then trivially used in RSpec for this 
>> purpose and could be useful outside of RSpec, too. Patrick, would you want 
>> to work with the Ruby core team to see if they're interested in that kind 
>> of improvement?
>>
>
> There's a question. Yes I'd be interested, it'd be great to give back to 
> the community. How would you propose starting? One possible good/bad thing 
> is that I'm taking a year out at the moment (currently in Argentina), so 
> having access to internet all the time isn't going to be that easy.  That, 
> and my partner will kill me if I just code all the time ;)  hehe, but, yes, 
> in principle I love the idea, just not sure where to start.
>  
>
>>
>> If you want to proceed with working off of what Ruby currently provides, 
>> I recommend building it as an RSpec extension gem.  Once it has proved 
>> useful, robust and stable in multiple projects we can consider rolling it 
>> into RSpec in a future version.
>>
>
> Yip, I might do that anyway, working to sort out an API with the core team 
> might take a while anyway. I've had a quick look for a guide to writing an 
> extension but didn't turn up anything immediate. Should I just look at how 
> other user contributed gems work and go from there.
>
> Many thanks for taking the time to respond, I hope I can put something 
> together that's useful. 
>
> Patrick
>
>  
>
>>
>> Myron
>>
>> On Sat, Feb 27, 2016 at 5:29 AM, Patrick Davey  
>> wrote:
>>
>>> I guess the question  is, whether it's possible to filter the warnings 
>>> in a way that is "simple, robust and clean" ?
>>>
>>> If there is no standard to the deprecations, and if they just call warn, 
>>> then (I guess?) there's no way to be sure you're not clobbering other 
>>> stderr. The risk would be that people would forget they'd left the 
>>> filtering on, and then miss subsequent warnings somehow. If an extra bit 
>>> out output was added to the end of an rspec run (with filtered warnings 
>>> enabled), which said something like "123 warnings have been filtered out", 
>>> then at least the developer would be reminded that they still had filtering 
>>> turned on.
>>>
>>> It seems to me that there is no way to do this cleanly, as there is no 
>>> way to be sure that you're not clobbering other uses of stderr based on 
>>> what Myron said. So, is a whitelist and reminder to the developer that 
>>> messages are being filtered a satisfactory approach?  It would, after all, 
>>> be a feature that developers would have to knowingly opt in to, and they'd 
>>> be doing it in order to keep their own code free of warnings.
>>>
>>> I'm only a consumer of rspec, never having looked at the internals, but 
>>> I'd be happy to try and get something working, assuming the approach was 
>>> one which was going to be satisfactory. 
>>>
>>>
>>>
>>> On Saturday, February 27, 2016 at 5:17:08 AM UTC-3, Jon Rowe wrote:
>>>>
>>>> Could we combine the logic we use to filter backtraces with the code

Re: [rspec] Rspec with warnings - ignore gems / whitelist directories

[Myron Marston]

>
> Could we combine the logic we use to filter backtraces with the code we
> use to detect warnings within our own specs and make something that could
> channel stderr through it and filter them?


I don't think our backtrace filtering logic could be applied to warnings
filtering.  Backtraces have a standard form that _always_ includes the file
name and is therefore easy to filter by file name or gem source.

Warnings, on the other hand, have no standard form and do not always
include file names.


Another thing to bear in mind is that RSpec's `--warnings` flag is only
intended to enable Ruby's warning mode -- which is an entirely different
thing from warnings emitted by ruby code calling `$stderr.warn` but which
is surfaced to the user in the same way (via $stderr).  It's not totally
clear to me what kind of warnings you're intending to solve, Patrick.

Personally, I wish Ruby itself provided APIs to control warnings more
tightly so that you could enable it for only particular files or
directories.  Such an API could then trivially used in RSpec for this
purpose and could be useful outside of RSpec, too. Patrick, would you want
to work with the Ruby core team to see if they're interested in that kind
of improvement?

If you want to proceed with working off of what Ruby currently provides, I
recommend building it as an RSpec extension gem.  Once it has proved
useful, robust and stable in multiple projects we can consider rolling it
into RSpec in a future version.

Myron

On Sat, Feb 27, 2016 at 5:29 AM, Patrick Davey 
wrote:

> I guess the question  is, whether it's possible to filter the warnings in
> a way that is "simple, robust and clean" ?
>
> If there is no standard to the deprecations, and if they just call warn,
> then (I guess?) there's no way to be sure you're not clobbering other
> stderr. The risk would be that people would forget they'd left the
> filtering on, and then miss subsequent warnings somehow. If an extra bit
> out output was added to the end of an rspec run (with filtered warnings
> enabled), which said something like "123 warnings have been filtered out",
> then at least the developer would be reminded that they still had filtering
> turned on.
>
> It seems to me that there is no way to do this cleanly, as there is no way
> to be sure that you're not clobbering other uses of stderr based on what
> Myron said. So, is a whitelist and reminder to the developer that messages
> are being filtered a satisfactory approach?  It would, after all, be a
> feature that developers would have to knowingly opt in to, and they'd be
> doing it in order to keep their own code free of warnings.
>
> I'm only a consumer of rspec, never having looked at the internals, but
> I'd be happy to try and get something working, assuming the approach was
> one which was going to be satisfactory.
>
>
>
> On Saturday, February 27, 2016 at 5:17:08 AM UTC-3, Jon Rowe wrote:
>>
>> Could we combine the logic we use to filter backtraces with the code we
>> use to detect warnings within our own specs and make something that could
>> channel stderr through it and filter them?
>>
>> Jon Rowe
>> ---
>> ma...@jonrowe.co.uk
>> jonrowe.co.uk
>>
>> On Saturday, 27 February 2016 at 05:14, Myron Marston wrote:
>>
>> Yes, it's worth doing -- provided it can be done in a simple, robust,
>> clean way.  I've made multiple attempts in the test suite of multiple
>> projects over the years to build something that does this but have never
>> found a solution that works well enough to include in RSpec itself.
>>
>> RSpec itself doesn't provide any sort of warnings mode...the `--warnings`
>> flag just turns on Ruby's warning mode and Ruby provides no way to filter
>> warnings.  Warnings are emitted to stderr so to filter you have to
>> intercept stderr output and find a way to filter it.  Problem is, there is
>> no standard warning message format, so you can't count on any thing in
>> particular (such as a gem name or file path) in the message to use to
>> filter.  On top of that, stderr contains output from many other things so
>> have to be careful to not accidentally silence other useful things.
>>
>> Myron
>>
>> On Fri, Feb 26, 2016 at 9:59 AM, Patrick Davey 
>> wrote:
>>
>> Hi,
>>
>> I have just got around to reading "The Pragmatic Programmer", long past
>> time, and one of the things it recommends is upping the warnings to the max
>> and fixing the lot. This sounded like good advice. So I added --warnings to
>> my .rspec and was swiftly flooded with a lot of warnings, quite

Re: [rspec] Rspec with warnings - ignore gems / whitelist directories

[Myron Marston]

Yes, it's worth doing -- provided it can be done in a simple, robust, clean
way.  I've made multiple attempts in the test suite of multiple projects
over the years to build something that does this but have never found a
solution that works well enough to include in RSpec itself.

RSpec itself doesn't provide any sort of warnings mode...the `--warnings`
flag just turns on Ruby's warning mode and Ruby provides no way to filter
warnings.  Warnings are emitted to stderr so to filter you have to
intercept stderr output and find a way to filter it.  Problem is, there is
no standard warning message format, so you can't count on any thing in
particular (such as a gem name or file path) in the message to use to
filter.  On top of that, stderr contains output from many other things so
have to be careful to not accidentally silence other useful things.

Myron

On Fri, Feb 26, 2016 at 9:59 AM, Patrick Davey 
wrote:

> Hi,
>
> I have just got around to reading "The Pragmatic Programmer", long past
> time, and one of the things it recommends is upping the warnings to the max
> and fixing the lot. This sounded like good advice. So I added --warnings to
> my .rspec and was swiftly flooded with a lot of warnings, quite a few from
> gems.
>
> I was wondering, is it possible with rspec to whitelist my application for
> warnings. That is, I'd like to see any bad code that I have introduced, but
> not anyone else. If not, is this something which would be worth adding?
>
> Thanks,
> Patrick
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/98c930c3-da5b-4360-9c8a-085f1f9f48ab%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsihH%3DAWv7Tb1BmaQovFm6W-GK%3DLHmfs5LWUgTLE0aA3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: how to test that methods are called inside a block?

[Myron Marston]

> However, what if we take this a step further, and say that we want to
call `CollaboratorB.bar` once inside the block and once outside the block
like this:

Remember that rspec-mocks allows you to pass an implementation block, which
flexibly allows you to do pretty much anything.  In this case you could do:

``` ruby
sequence = []
allow(CollaboratorB).to receive(:bar) { sequence << :bar }
allow(CollaboratorA).to receive(:foo) do |&block|
  sequence << :foo_start
  block.call
  sequence << :foo_end
end

baz

expect(sequence).to eq [:foo_start, :bar, :foo_end, :bar]
```

For the `fetch_product` case, you could do something similar.  Although,
personally I wouldn't test a method like that with mocks at all: I'd tend
to integration test it.

Anyhow, as for adding something more explicit to support this directly from
the rspec-mocks API: I think we'd want to hear that this is a more common
problem with our users to warrant adding that complexity to RSpec.   I
can't think of a time I've ever wanted that and I can't think of any user
requesting it before.  It's a complex thing and the `inside`/`outside`
thing you've come up with reads pretty well but it's pretty different from
the rest of the rspec-mocks API to get a result from setting up a prior
stub and use it in a later one.

HTH,
Myron

On Mon, Feb 15, 2016 at 3:28 PM, Nathan Wenneker 
wrote:

> I know I'm replying to an old thread, but it seemed relevant.
>
> Suppose we want to unit test in pure isolation a method that passes a
> block to a collaborator.  For example:
>
> def baz
>   CollaboratorA.foo do
> CollaboratorB.bar
>   end
> end
>
> It's important not only that `baz` calls `CollaboratorB.bar`, but that it
> does it inside the block. Myron's gist
> <https://gist.github.com/myronmarston/e79cbff12ce51b54814b> from a year
> ago answers this question well.  However, what if we take this a step
> further, and say that we want to call `CollaboratorB.bar` once inside the
> block and once outside the block like this:
>
> def baz
>   CollaboratorA.foo do
> CollaboratorB.bar
>   end
>   CollaboratorB.bar
> end
>
> Furthermore, let's suppose we want to assemble the return values from
> these two `bar` calls.  This isn't a Rails specific question, but I'll use
> `ActiveRecord::Base.unscoped` (assuming a default_scope is set) as a
> real-world example that I hope will be easily understood:
>
> def fetch_products
>   visible_products = Product.all
>   all_products = Product.unscoped do
> Product.all
>   end
>   { visible_products: visible_products, all_products: all_products }
> end
>
> I know that an isolated test for this will be tightly coupled to the
> implementation, but assuming that's what we want to do, I imagined a new a
> new `inside` and `outside` API for rspec-mocks, and this is how I would
> test `fetch_products`:
>
> it "fetches products" do
>   all_products = double("all products")
>   visible_products = double("visible products")
>
>   unscoped = allow(Product).to receive(:unscoped).and_yield
>   allow(Product).to
> receive(:all).inside(unscoped).and_return(all_products)
>   allow(Product).to
> receive(:all).outside(unscoped).and_return(visible_products)
>
>   expect(fetch_products).to eq({
> visible_products: visible_products,
> all_products: all_products
>   })
>
> end
>
> If you didn't have return values to compare against, you could also write
> something like:
>
> expect(Product).to have_received(:all).inside(unscoped).once
> expect(Product).to have_received(:all).outside(unscoped).once
>
>
> So I have a two questions:
>
>  1. Is there a straightforward way to write this spec using the current
> API?
>  2. If not, would you be open to a PR that adds the `inside` and `outside`
> API, or open to discussing an alternative API that would make this kind of
> spec feasible?
>
> I have a working prototype locally that enhances `@messages_received` to
> track what existing message expectations are running an implementation when
> a subsequent message is called, which can then be compared to to
> constraints.
>
> Thank you,
>
> Nathan
>
> On Thursday, March 5, 2015 at 9:16:31 PM UTC-7, Myron Marston wrote:
>>
>> On Thursday, March 5, 2015 at 7:06:58 PM UTC-8, Joe Van Dyk wrote:
>>>
>>> Say I have the following method:
>>>
>>>   def run
>>> transaction do
>>>   mark_non_eligible
>>>   make_invoice_

Re: [rspec] Verify that a method receives a particular block

[Myron Marston]

As Jon pointed out, the rspec-mocks API allows you to use blocks to specify
implementation logic and/or return values so I don’t think that making it
also match on the block will work well. The solution you came up with looks
OK to me. You could shorten it further with a helper method:

module ReceiveWithBlock
  def receive_with_block(method_name, &expected_block)
receive(method_name) { |&block| expect(block).to eq expected_block }
  endend
RSpec.configure do |config|
  config.include ReceiveWithBlockend

Which you could then use with:

expect(Foo).to receive_with_block(:baz, &my_block)

Given the rarity of this need and that there are solutions, I would lean
against adding anything additional to the RSpec API for it.

Myron
​


On Thu, Feb 18, 2016 at 3:13 PM, Jon Rowe  wrote:

> The problem with block arguments is there priority with Ruby… Consider
> that this:
>
> it “returns my value" do
>   expect(Foo).to receive(:baz) { “my return value” }
> end
>
> Needs to return the same as this:
>
> it “still returns my value" do
>   expect(Foo).to receive(:baz).with(:my_argument) { “my return value” }
> end
>
> And that is the same as this:
>
> it “still returns my value” do
>   my_block = lambda { “my return value” }
>   expect(Foo).to receive(:baz).with(:my_argument,&my_block)
> end
>
> And hopefully you can see why it doesn’t (and intend can’t) work the way
> you want it currently…
>
> I’d be open to adding another way to match this however, maybe an argument
> matcher?
>
> it "passes the given block to Foo" do
>   my_block = lambda {}
>
>   # pseudo code, won’t work atm
>   expect(Foo).to receive(:baz).with(block_argument(my_block))
>
>   Bar.baz_wrapper(&my_block)
> end
>
> Jon Rowe
> ---
> m...@jonrowe.co.uk
> jonrowe.co.uk
>
> On Friday, 19 February 2016 at 09:47, Nathan Wenneker wrote:
>
> I want to verify that this method passes a block to a collaborator:
>
>
> module Bar
>   def self.baz_wrapper(&block)
> Foo.baz(&block)
>   end
> end
>
> Something like this would be nice:
>
> it "passes the given block to Foo" do
>   my_block = lambda {}
>
>   expect(Foo).to receive(:baz).with(&my_block)
>
>   Bar.baz_wrapper(&my_block)
> end
>
> However, the best I could come up with is this:
>
>
> it "passes the given block to Foo" do
>   my_block = lambda {}
>
>   expect(Foo).to receive(:baz) do |&block|
> expect(block).to eq(my_block)
>   end
>
>   Bar.baz_wrapper(&my_block)
> end
>
> Questions.
>
> 1. Is there a better way to do this?
>
> 2. If not, would you be open to a discussion on making `expect(Foo).to
> receive(:baz).with(&my_block)` work?
>
>
> Thank you,
>
> Nathan
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/3bfa0a8a-4f55-4e24-8527-3f2f4eb693ea%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/EB121FFFE7C64891924A7F6D1148B377%40jonrowe.co.uk
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtp2MM4_OAJfS6zVt4mBjSxaN%3DKGXJcrUXOUSpFL8%2BG0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: Updating rspec from 3.0.0 to 3.1

[Myron Marston]

No one has reported a bug like that before.  Nothing comes to mind that
could be the cause, either.  Can you provide an executable example of the
bug?  Without that there's not much we can do because we can't guess what's
different about your test suite that causes the problem.

On Thu, Feb 4, 2016 at 10:54 AM, Mohit Gupta  wrote:

> Yes, I am trying to run a single spec. But the problem is instead of
> running that single spec it picks up some random spec when I update the
> rspec version.
>
> On Wednesday, February 3, 2016 at 5:24:53 PM UTC-8, Mohit Gupta wrote:
>>
>> Hi All
>>
>> Need Urgent help regarding updating rspec version from 3.0.0 to 3.1.
>>
>> I have updated the version in gemfile, and I did bundle update rspec and
>> then verified it using bundle again. After that when I specify a particular
>> spec, that spec is not executed but other random spec is executed.
>> Please let me know what am I doing wrong or am I missing any step?
>>
>> Thanks
>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/44eee709-7a9a-4991-bf56-1e5524ce1443%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvYwfSui1QOzoZOPuj4_m3poJ0tMfBRTQZsr6o6PHcmCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] RSpec 3.2 Model Testing Error in Rails Mountable Engine

[Myron Marston]

Looking at your stack trace, it looks like the bit of code that's
triggering ActiveRecord to try to load the schema is a `create_or_update`
call at ./lib/hc/qb/create_or_update_invoice.rb:17.  Are you sure the RSpec
stubbing line is what's causing the error?  The stack trace makes it look
like it's not.

HTH,
Myron

On Tue, Feb 2, 2016 at 12:40 PM, Adam Perry-Pelletier  wrote:

> Myron,
>
> Thanks for the help, but the same thing still occurs. I had tried expect
> syntax and just retried.
>
> expect(User).to receive(:find_by_user_id_and_type).with(42,
> 'GREAT_USER').and_return(user)
>
> As before, the result is.
>
> ActiveRecord::StatementInvalid: Could not find table 'users'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/connection_adapters/sqlite_adapter.rb:472:in
> `table_structure'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/connection_adapters/sqlite_adapter.rb:346:in
> `columns'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/connection_adapters/schema_cache.rb:12:in
> `block in initialize'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/model_schema.rb:229:in
> `yield'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/model_schema.rb:229:in
> `columns'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/model_schema.rb:249:in
> `column_names'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/model_schema.rb:262:in
> `column_methods_hash'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/dynamic_matchers.rb:74:in
> `all_attributes_exists?'
> /Users/mp/.rvm/gems/ruby-2.1.2_hc-2.1.2/gems/activerecord-3.2.21/lib/active_record/dynamic_matchers.rb:27:in
> `method_missing'
> ./lib/hc/qb/create_or_update_invoice.rb:17:in `create_or_update'
> ./spec/create_or_update_invoice_spec.rb:233:in `block (4 levels) in  (required)>'
> -e:1:in `load'
> -e:1:in `'
>
> Unlike 1.x, if 3.4 even touches an ActiveRecord class it tries to load it
> from the schema, before it is actually used.
>
> Thanks,
> Adam
>
> On Tuesday, February 2, 2016 at 11:46:49 AM UTC-8, Myron Marston wrote:
>>
>> In rspec 3.2, we changed to
>>> allow(User).to receive(:find_by_user_id_and_type).with(42,
>>> 'GREAT_USER').and_return(user)
>>
>>
>> This is not equivalent to what you had before. The equivalent of
>> `User.should_receive` in the new syntax is `expect(User).to receive`.
>>  `allow` is the equivalent of a stub.
>>
>> As for the error you're getting: I believe it is related to verifying
>> doubles.  It is trying to validate that `find_by_user_id_and_type` is a
>> valid method -- but to verify that, the schema must be loaded to see if the
>> model has `user_id` and `type` fields.  If you don't want partial doubles
>> to have that kind of verification, you can turn it off with a config option:
>>
>>
>> https://www.relishapp.com/rspec/rspec-mocks/docs/verifying-doubles/partial-doubles
>>
>> HTH,
>> Myron
>>
>> On Tue, Feb 2, 2016 at 11:38 AM, Adam Perry-Pelletier <
>> ad...@tryhousecall.com> wrote:
>>
>>> In old RSpec, in a Rails Mountable Engine project with no database
>>> underneath. We have the following expectation set up.
>>>
>>> User.should_receive(:find_by_user_id_and_type).with(42,
>>> 'GREAT_USER').and_return(user)
>>>
>>> The above worked fine.
>>>
>>> In rspec 3.2, we changed to
>>>
>>> allow(User).to receive(:find_by_user_id_and_type).with(42,
>>> 'GREAT_USER').and_return(user)
>>>
>>> This now fails with the error:
>>>
>>> ActiveRecord::StatementInvalid: Could not find table 'users'
>>>
>>> It appears in rspec 3.4 when the expectation is set up, rspec does try
>>> to load the ActiveRecord properties from the database. The old rspec did
>>> not do this. This allowed us to write rspec tests against a Rails Mountable
>>> Engine project without actually having to load and configure a test
>>> database. The database for this project is loaded and available in the main
>>> project which uses this subproject.
>>>
>>> Thanks in advance for any help.
>>> Adam
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the G

Re: [rspec] RSpec 3.2 Model Testing Error in Rails Mountable Engine

[Myron Marston]

>
> In rspec 3.2, we changed to
> allow(User).to receive(:find_by_user_id_and_type).with(42,
> 'GREAT_USER').and_return(user)


This is not equivalent to what you had before. The equivalent of
`User.should_receive` in the new syntax is `expect(User).to receive`.
 `allow` is the equivalent of a stub.

As for the error you're getting: I believe it is related to verifying
doubles.  It is trying to validate that `find_by_user_id_and_type` is a
valid method -- but to verify that, the schema must be loaded to see if the
model has `user_id` and `type` fields.  If you don't want partial doubles
to have that kind of verification, you can turn it off with a config option:

https://www.relishapp.com/rspec/rspec-mocks/docs/verifying-doubles/partial-doubles

HTH,
Myron

On Tue, Feb 2, 2016 at 11:38 AM, Adam Perry-Pelletier  wrote:

> In old RSpec, in a Rails Mountable Engine project with no database
> underneath. We have the following expectation set up.
>
> User.should_receive(:find_by_user_id_and_type).with(42,
> 'GREAT_USER').and_return(user)
>
> The above worked fine.
>
> In rspec 3.2, we changed to
>
> allow(User).to receive(:find_by_user_id_and_type).with(42,
> 'GREAT_USER').and_return(user)
>
> This now fails with the error:
>
> ActiveRecord::StatementInvalid: Could not find table 'users'
>
> It appears in rspec 3.4 when the expectation is set up, rspec does try to
> load the ActiveRecord properties from the database. The old rspec did not
> do this. This allowed us to write rspec tests against a Rails Mountable
> Engine project without actually having to load and configure a test
> database. The database for this project is loaded and available in the main
> project which uses this subproject.
>
> Thanks in advance for any help.
> Adam
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/68e6bdcf-a228-45c4-bcd8-c12b1e31af1e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsG1nBVAem0eVA4TumuALAyiAM2_rWACVOzo-iBc7Wrcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Conditional statements

[Myron Marston]

RSpec doesn't modify the ruby interpreter in any way, so constructs that
are possible in Ruby are possible in RSpec.  In ruby you have to use
`elsif` (not `elseif`).

HTH,
Myron

On Fri, Jan 29, 2016 at 10:23 AM, Sasha S  wrote:

> I am trying to create a conditional block like;
> if
>  action
> elseif
>   action
> else
>
>
> I cannot find anywhere the correct way for elseif part of this block.  Is
> it possible in RSpec?
>
> Thanks,
> Sasha
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/a7c9ef38-8271-4b6e-be27-a2306bd0727a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtR%2BZ58rjDwybq169R-aws9MRwAQPrb4snpEm1XUY4-cA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Rails 4.2.5.1 breakage

[Myron Marston]

Please do cut a release with a fix :).  It's great that I'm no longer the
bottleneck on such thing!

On Mon, Jan 25, 2016 at 2:37 PM, 'Sam Phippen' via rspec <
rspec@googlegroups.com> wrote:

> Hi Everyone,
>
> When Rails cut 4.2.51, they broke RSpec rails for some people as
> documented in this thread:
> https://github.com/rspec/rspec-rails/issues/1532.
>
> A PR is open against us to fix it here:
> https://github.com/rspec/rspec-rails/pull/1533
>
> It’s nearly bedtime here in the UK, but if anyone can coach that person
> through slash implement a spec themselves overnight, that’d be spectacular,
> otherwise, I’ll sort it tomorrow morning.
>
> Would everyone be OK with me releasing a patch level gem of RSpec Rails
> only which includes that fix if necessary?
>
> Thanks
> —
> Sam Phippen
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/91F898C0-3D72-4DA5-A60A-3B6FD660D328%40googlemail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQms1qtMEYGZdY1QWFfF-cETAhEr2ZAYsSLf%2BggBjezBpjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] signing key

[Myron Marston]

https://gist.github.com/myronmarston/d0c0e6377c0ac6f60e67

On Sun, Jan 10, 2016 at 4:08 PM, 'Sam Phippen' via rspec <
rspec@googlegroups.com> wrote:

> Hi Myron,
>
> Turns out, sending me the passphrase may not be necessary,
>
> can you copy the `rspec-gem-private_key.pem` file into a working directory
> and then run
>
> ```
> gpg --encrypt -r “Sam” --sign --armor rspec-gem-private_key.pem
> ```
>
> that’ll create rspec-gem-private_key.pem.asc. That file is safe to paste
> into a gist.
> If you do that and send it to me, I’ll let you know if I can decrypt it.
>
> Thanks
> —
> Sam Phippen
>
>
>
> On 11 Jan 2016, at 00:04, Myron Marston  wrote:
>
> Here's my shasums:
>
> ```
> ➜  rspec-mocks git:(master) shasum ~/.gem/rspec-gem-p*
> 7bed550731bbecd728811391c974450195513929
>  /Users/myron/.gem/rspec-gem-private_key-2.from_sam
> 45395f4733a49a707f312b7dc3ff3d73e0b657dd
>  /Users/myron/.gem/rspec-gem-private_key.pem
> da39a3ee5e6b4b0d3255bfef95601890afd80709
>  /Users/myron/.gem/rspec-gem-private_key_2.pem
> 9c3ef569e881c27986433fc6f4a80d0e21e5b674
>  /Users/myron/.gem/rspec-gem-public_cert.pem
>
> ```
>
> Some of the those files are old backup files that can be ignored.
>
> > Additionally, can you encrypt and sign the passphrase you use to sign
> the key to my public key?
>
> If I knew how to do that, I would.  The only times I've ever used the
> encryption tools you showed me how to use are the two times we've skyped to
> exchange files, and each time I've promptly forgotten everything I know
> about them.  (My brain only has so much room for new stuff these days,
> sorry!).
>
> Do you have a server I could scp the passphrase on to?  You can get my
> public keys [off of github](https://github.com/myronmarston.keys).
>
> BTW, what is the plan for releasing rails 5 support?
>
> Myron
>
>
> On Sun, Jan 10, 2016 at 3:56 PM, 'Sam Phippen' via rspec <
> rspec@googlegroups.com> wrote:
>
>> Hi Everyone,
>>
>> Myron, I’ve checked and as far as I can tell I have the right signing
>> key, public key and passphrase, but I’m getting an error on signing.
>> Can you currently successfully build the RSpec gems?
>>
>> If so, can you send me and Jon the output of:
>>
>> `shasum ~/.gem/rspec-gem-p*`
>>
>> Additionally, can you encrypt and sign the passphrase you use to sign the
>> key to my public key?
>>
>> (I’m assuming you and Jon haven’t cosigned keys, but I’ll forward it to
>> him if I can verify my build)
>>
>> thanks
>> —
>> Sam Phippen
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to rspec@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/rspec/242CB7AB-0FE6-4530-8A72-F172DA38B62C%40googlemail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/CADUxQmt4es66psfsrqiYBoua%2BL0krOWOFnb%3DWdeOonYaW11sBQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/rspec/CADUxQmt4es66psfsrqiYBoua%2BL0krOWOFnb%3DWdeOonYaW11sBQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/D060F100-9EF3-4CA3-AB75-772F46FD8087%40googlemail.com
> <https://groups.google.com/d/msgid/rspec/D060F100-9EF3-4CA3-AB75-772F46FD8087%40googlemail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmt1Y7q13fvE5iMCb31f3w-FQaz7VdBasuZSyHRc_JD_DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] signing key

[Myron Marston]

Here's my shasums:

```
➜  rspec-mocks git:(master) shasum ~/.gem/rspec-gem-p*
7bed550731bbecd728811391c974450195513929
 /Users/myron/.gem/rspec-gem-private_key-2.from_sam
45395f4733a49a707f312b7dc3ff3d73e0b657dd
 /Users/myron/.gem/rspec-gem-private_key.pem
da39a3ee5e6b4b0d3255bfef95601890afd80709
 /Users/myron/.gem/rspec-gem-private_key_2.pem
9c3ef569e881c27986433fc6f4a80d0e21e5b674
 /Users/myron/.gem/rspec-gem-public_cert.pem

```

Some of the those files are old backup files that can be ignored.

> Additionally, can you encrypt and sign the passphrase you use to sign the
key to my public key?

If I knew how to do that, I would.  The only times I've ever used the
encryption tools you showed me how to use are the two times we've skyped to
exchange files, and each time I've promptly forgotten everything I know
about them.  (My brain only has so much room for new stuff these days,
sorry!).

Do you have a server I could scp the passphrase on to?  You can get my
public keys [off of github](https://github.com/myronmarston.keys).

BTW, what is the plan for releasing rails 5 support?

Myron


On Sun, Jan 10, 2016 at 3:56 PM, 'Sam Phippen' via rspec <
rspec@googlegroups.com> wrote:

> Hi Everyone,
>
> Myron, I’ve checked and as far as I can tell I have the right signing key,
> public key and passphrase, but I’m getting an error on signing.
> Can you currently successfully build the RSpec gems?
>
> If so, can you send me and Jon the output of:
>
> `shasum ~/.gem/rspec-gem-p*`
>
> Additionally, can you encrypt and sign the passphrase you use to sign the
> key to my public key?
>
> (I’m assuming you and Jon haven’t cosigned keys, but I’ll forward it to
> him if I can verify my build)
>
> thanks
> —
> Sam Phippen
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/242CB7AB-0FE6-4530-8A72-F172DA38B62C%40googlemail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmt4es66psfsrqiYBoua%2BL0krOWOFnb%3DWdeOonYaW11sBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Does SummaNotification#duration within rspec-core measure time taken to make DB calls?

[Myron Marston]

Yes. RSpec simply measures the time between *just before* the first spec
runs until *just after* the last spec finishes. It does not attempt to
distinguish between different activities that take up that time, such as
setting objects up and making DB calls.

Note that we do measure load time separately, however.
SummaryNotification#load_time measures the time from when RSpec begins to
get loaded until the spec files have all been loaded. Importantly, this
does not include the boot time of Ruby itself or anything that loads or
executes before RSpec (such as rake or bundler).

Myron
​

On Sun, Jan 3, 2016 at 5:45 AM,  wrote:

> Hey Folks
>
>
> `SummaryNotification#duration` measures the time taken to run the test
> suite, does this time that is returned include how long it took a test
> suite to set objects up, make db calls etc?
>
> Thanks Adam
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/7eb116bb-4e4b-4017-802b-07df26729a4d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvR5E%3DkmLeWfcuytZVnu9Pt3neOVJhbDfyN0oRYk-yi6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: Hiding backtraces and using symlinks

[Myron Marston]

s/2.0.0/gems/rspec-expectations-3.4.0/lib/rspec/expectations/expectation_target.rb:54:in
>> `to'
>>
>>  # /Users/crosson/bin/example:13:in `block (2 levels) in '
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example.rb:236:in
>> `instance_exec'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example.rb:236:in
>> `block in run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example.rb:477:in
>> `block in with_around_and_singleton_context_hooks'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example.rb:434:in
>> `block in with_around_example_hooks'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/hooks.rb:478:in
>> `block in run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/hooks.rb:616:in
>> `run_around_example_hooks_for'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/hooks.rb:478:in
>> `run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example.rb:434:in
>> `with_around_example_hooks'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example.rb:477:in
>> `with_around_and_singleton_context_hooks'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example.rb:233:in
>> `run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example_group.rb:581:in
>> `block in run_examples'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example_group.rb:577:in
>> `map'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example_group.rb:577:in
>> `run_examples'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/example_group.rb:543:in
>> `run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:115:in
>> `block (3 levels) in run_specs'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:115:in
>> `map'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:115:in
>> `block (2 levels) in run_specs'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/configuration.rb:1680:in
>> `with_suite_hooks'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:114:in
>> `block in run_specs'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/reporter.rb:77:in
>> `report'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:113:in
>> `run_specs'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:89:in
>> `run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:73:in
>> `run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:41:in
>> `invoke'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:34:in
>> `perform_at_exit'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-3.4.1/lib/rspec/core/runner.rb:20:in
>> `block in autorun'
>>
>>  #
>>
>>  #   Showing full backtrace because every line was filtered out.
>>
>>  #   See docs for RSpec::Configuration#backtrace_exclusion_patterns
>> and
>>
>>  #   RSpec::Configuration#backtrace_inclusion_patterns for more
>> information.
>>
>>
>> Finished in 0.03689 seconds (files took 0.15154 seconds to load)
>>
>> 1 example, 1 failure
>>
>>
>> Failed examples:
>>
>>
>> rspec /Users/crosson/bin/example:11 # TEST A >>  1:Ping is true >>
>>
>>
>> Cliffords-iMac:Desktop crosson$ ls ~/bin/
>>
>> example
>>
>> Cliffords-iMac:Desktop crosson$ ls -l ~/bin/
>>
>> total 8
>>
>> lrwxr-xr-x  1 crosson  staff  41 Dec 31 16:59 example ->
>> /Users/crosson/Desktop/scratch/example.rb
>>
>>
>>
>>
>> Cliffords-iMac:D

Re: [rspec] Re: Hiding backtraces and using symlinks

[Myron Marston]

Our website has detailed upgrade instructions:

http://rspec.info/upgrading-from-rspec-2/

Besides upgrading to 2.99 first, the other important thing is using
transpec.

HTH,
Myron

On Thu, Dec 31, 2015 at 4:51 PM, Cliff Rosson 
wrote:

> Thanks Jon. I'll give it a shot. I ran into some semantic issues when
> rspec released 3.0 some time ago but in reading the docs nothing really
> stands out on why rspec3 wouldn't work for me.
>
> On Thursday, December 31, 2015 at 4:08:09 PM UTC-8, Jon Rowe wrote:
>>
>> Full backtrace is actually designed to force a full backtrace display,
>> turning it off merely uses the default inclusion / exclusion filters, by
>> default (if I remember correctly) this includes stuff based on your working
>> directory; so if you manually add the directory (even if you use ruby to
>> generate it from the file rather than the working directory) to the
>> exclusion filter it should be removed no matter where you run the test from.
>>
>> There’s been a fair amount of work on improving this behaviour in RSpec 3
>> and given that RSpec 2 isn’t supported I heartily recommend you upgrade to
>> the latest version, if you install 2.99 first it will be relatively
>> painless!
>>
>> Cheers
>> Jon
>>
>> Jon Rowe
>> ---
>> ma...@jonrowe.co.uk
>> jonrowe.co.uk
>>
>> On Friday, 1 January 2016 at 04:52, Cliff Rosson wrote:
>>
>> Versions.
>>
>> rspec (2.14.1)
>>
>> rspec-core (2.14.8)
>>
>> rspec-expectations (2.14.5)
>>
>> rspec-mocks (2.14.6)
>>
>> On Wednesday, December 30, 2015 at 9:52:45 PM UTC-8, Cliff Rosson wrote:
>>
>> Hi Folk,
>>
>> Hopefully this is a very simple question. I use RSPEC as a functional
>> test for network maintenances. It allows me to loop a series of tests
>> during a maintenance providing a clean format and notification of any
>> behavioral changes on the network.
>>
>> Often times I expect some things to fail and in an attempt to keep
>> results clean I often want to hide the full backtrace. If I run my rspec
>> with the config.full_backtrace argument set to false everything works
>> great. If I symlink the file however the backtraces return.
>>
>> I wrote this example to illustrate my issue.
>>
>> #!/usr/bin/ruby
>> require 'rspec/autorun'
>> require 'net/ping'
>>
>>
>> RSpec.configure do |config|
>>   config.full_backtrace=false
>> end
>>
>> describe "TEST A >> " do
>>   it "1:Ping is true >> " do
>> host = Net::Ping::External.new("www.google.com")
>> host.ping?.should be_false
>>   end
>> end
>>
>>
>> if I run this directly it works great.
>>
>> /test_rspec.rb
>>
>> F
>>
>>
>> Failures:
>>
>>
>>   1) TEST A >>  1:Ping is true >>
>>
>>  Failure/Error: Unable to find matching line from backtrace
>>
>>expected: false value
>>
>> got: true
>>
>>  # ./test_rspec.rb:13:in `block (2 levels) in '
>>
>>
>> Finished in 0.01479 seconds
>>
>> 1 example, 1 failure
>>
>>
>> Failed examples:
>>
>>
>> rspec ./test_rspec.rb:11 # TEST A >>  1:Ping is true >>
>>
>>
>> Nice and clean output.
>> However if I symlink the file I get the full backtrace which I really
>> just would rather ignore.
>>
>> ls -l ~/bin/
>>
>> total 24
>>
>> lrwxr-xr-x  1 cliff.rosson  USERS\Domain Users  49 Dec 30 16:56
>> test_rspec -> /Users/cliff.rosson/Desktop/scratch/test_rspec.rb
>>
>>
>>
>> And run the symlink
>>
>> test_rspec
>>
>> F
>>
>>
>> Failures:
>>
>>
>>   1) TEST A >>  1:Ping is true >>
>>
>>  Failure/Error: host.ping?.should be_false
>>
>>expected: false value
>>
>> got: true
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-expectations-2.14.5/lib/rspec/expectations/fail_with.rb:32:in
>> `fail_with'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-expectations-2.14.5/lib/rspec/expectations/handler.rb:36:in
>> `handle_matcher'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-expectations-2.14.5/lib/rspec/expectations/syntax.rb:53:in
>> `should'
>>
>>  # /Users/cliff.rosson/bin/test_rspec:13:in `block (2 levels) in
>> '
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:114:in
>> `instance_eval'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:114:in
>> `block in run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:254:in
>> `with_around_each_hooks'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example.rb:111:in
>> `run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:390:in
>> `block in run_examples'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:386:in
>> `map'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:386:in
>> `run_examples'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/rspec/core/example_group.rb:371:in
>> `run'
>>
>>  #
>> /Library/Ruby/Gems/2.0.0/gems/rspec-core-2.14.8/lib/r

Re: [rspec] Sideband error reporting to rspec

[Myron Marston]

Try this:

class RSpecLogger
  def errors
@errors ||= []
  end

  def error(e)
errors << e
  endend
RSpec.configure do |c|
  c.before do
@rspec_logger = RSpecLogger.new
  end

  c.after do
expect(@rspec_logger.errors).to be_empty,
  "Got some logged errors:
#{@rspec_logger.errors.map(&:message).join("\n")}"
  endend

​

On Wed, Nov 25, 2015 at 8:13 AM, Tim Mertens  wrote:

> Happy Thanksgiving!
>
> I am testing an application that reports all errors through a common
> interface, which then distributes errors to various loggers (rails logs,
> logentries, etc).  Each reporter logs messages based on severity and
> environment.  In our test environment, the generic logging interface is set
> to always re-raise reported errors such that tests will always fail if an
> error is reported through this interface that is not expected.  In the
> majority of cases, this means that conditions where such errors would
> normally be reported, handled and swallowed in production will instead
> re-raise the exception (in test) and ultimately cause the test to fail if
> the error is not explicitly expected.
>
> However, we still observe conditions where:
>
>1. class A calls class B calls class C.
>2. class C raises an exception.
>3. class B catches said exception and logs it via the Logger.
>4. The Logger re-raises the error.
>5. class A catches the re-raised error but swallows it completely.
>6. The test passes if there are no failing expectations as a result,
>even though an exception occurred.
>
> Is there some way to report errors to rspec via a sideband messaging
> channel, such that we can implement a logger that would simply report
> errors directly to rspec and bypass the need for an exception to bubble all
> the way up to the top of the stack in order for a test to fail?
>
> The only possible solution I know of so far would be to set a global
> expectation for the logging class not to receive an error message, and
> override that behavior in individual tests; however, this feels like the
> wrong solution and I'm not sure it would actually work as desired to modify
> the expectation behavior from `expect().not_to receive` (in a global before
> hook) to `allow().to receive`, or `expect().to receive`.  Or we would have
> to override the default expectation via metadata in individual tests which
> again is not an ideal solution.
>
> Here is a rudimentary example of the problem:
>
> class RSpecLogger
>   def error(e)
> # somehow report sideband error to rspec
>   end
> end
>
> class SomeOtherReporter
>   def error(e)
> puts e.message
>   end
> end
>
> class MyErrorLogger
>   LOGGERS = [
> SomeOtherReporter.new,
> RSpecLogger.new
>   ]
>
>   def self.error(exception)
> LOGGERS.each { |r| r.error(exception) }
>
> raise exception if should_reraise? # This could be replaced entirely
> via sideband reporting
>   end
>
>   def self.should_reraise?
> true # if in test environment
>   end
> end
>
> describe MyErrorLogger do
>   it 'should fail even if reraise is caught elsewhere' do
> begin
>   begin
> # Something raises an exception
> raise StandardError.new("Foo message")
>   rescue => e
> # We rescue and log it
> described_class.error(e)
>   end
> rescue => e
>   # the reraised error is swallowed somewhere further up the stack, so
> the test passes if no assertions fail.
>   nil
> end
>   end
> end
>
> Thanks,
> Tim
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/d0fcb0da-8578-49f0-be1e-9a9094276fe0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsrCoH2QYjYqr0tNu7d2tZgqS1yBpC54WnTWqcVWAY1hw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Passing parameters to a shared context group?

[Myron Marston]

Yes, you can pass arguments to both, and it's completely safe to do so.

On Tue, Nov 17, 2015 at 11:07 PM, George Mendoza 
wrote:

> Hello RSpec team,
>
> Our team recently discovered that it's possible to pass parameters to a
> shared_context group. Is it safe to do so? I have read from the Difference
> between shared_examples and shared_context
>  thread
> that shared_examples and shared_contexts are just aliases. However, AFAIK,
> passing parameters to a shared examples group is only documented for the
> shared examples
>  group.
>
> Thanks and more power!
>
> George Mendoza
> Philippines
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/aa709afa-c203-403a-9d55-1b22cfcca28e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmswN22E0yRm3iR2aRYZJ34K6VQWOsVvsujHv_q5tsvbJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Question on implementing rspec test using concurrency with threads, etc.

[Myron Marston]

>
> This is my black box test scenario, for testing a stream processing
> microservice:
> Test input via Rspec > microservice > output to validate with Rspec


So you're trying to use RSpec in your production code to validate input and
output, as a way of doing runtime assertions?  That's not a very common
approach (I've not heard of any one doing it before, honestly!) but it's
certainly doable with rspec-expectations.  Just `include RSpec::Matchers`
in your class and the typical expectation syntax (e.g. `expect(value).to
whatever`) will be available in the instance methods of your class.

You also mention Apache Kafka causing difficulties for testing.  Here's my
suggestion to deal with that:

   - Come up with an abstract interface that provides access to the minimal
   set of Apache Kafka features your app needs.
   - Write an implementation of that interface that works by wrapping Kafka
   and delegating to it internally.
   - Write an alternate implementation that instead uses something far
   simpler, easier to reason about and easier to control such as Ruby's Queue
   library.
   - Use this alternate implementation for your unit tests so that you can
   easily control the input to your system in your isolated unit tests.
   - Use the implementation that wraps Kafka in production.
   - Write a small number (potentially as few as 1!) integration tests that
   use the Kafka implementation.  Use these tests to verify that your code
   works with the kafka implementation and that it works properly when all
   wired together, but don't make detailed assertions about your logic --
   that's what the unit tests are for.

Myron

On Sat, Nov 14, 2015 at 11:49 AM, David Luu  wrote:

> Thanks for the response. I'll look into your current suggestions.
>
> This is my black box test scenario, for testing a stream processing
> microservice:
>
> Test input via Rspec > microservice > output to validate with Rspec
>
> This is testable sequentially via the message bus' queue (and using
> offsets to fetch from queue to be exact and safe), when tested under
> isolation. That is feed input, then afterwards fetch outputvia offsets to
> validate.
>
> But in actual complete test environment with multiple microservices
> connected to form the system, the isolated test approach doesn't work
> reliably, as other consumers consume the data live, and using offsets
> doesn't appear to sync quite right compared to the isolated environment.
> Plus we will eventually implement scalability enhancements utilizing the
> message bus technology that make the consume by offset method even harder.
>
> So I was considering running the code that feeds the test data and the
> output validation concurrently, validate as output comes out based on the
> input fed in. The input thread could finish first and main thread will wait
> for output validation thread to complete to exit, although in general both
> input, output threads should complete relatively around the same time, as
> the processing by the microservice happens nearly in real time.
>
> The queue class suggestion, at least in the example in the docs, doesn't
> quite work for me, at least in the sense of adding/removing from the queue,
> because I don't control the queue, the queue itself is the (Apache Kafka)
> message bus that the data flows through which the microservice processes.
> The rspec test simply utilizes Ruby code to attach to the bus to produce
> and consume the data. So my reliability of dealing with the queue is the
> reliability of dealing with kafka in Ruby. And kafka is meant as a real
> time message bus, so I should be producing & consuming in the same way for
> testing, ideally.
>
> It occurred to me that I could also just use parts of Rspec like the
> expectations and matchers and not use the full rspec framework to make
> structuring this test easier, although I do prefer to keep it full rpsec
> with the describe and it blocks.
>
> I hope that adds clarity to my test intentions. So I'm not actually or
> directly testing concurrency but that I need to utilize it to facilitate
> the testing.
>
> On Friday, November 13, 2015 at 11:55:28 PM UTC-8, Myron Marston wrote:
>>
>> It's hard for me to answer your question because your code confuses so
>> I'm not sure what your intent is.  If you can update it to be a little more
>> concrete that would help.  Here's a few thoughts, though
>>
>>
>>- It looks like you are trying to run an RSpec spec inside your
>>`consume` method in a thread.  That's not going to work.  RSpec takes
>>responsibility for running your specs at an appropriate time in the
>>runner's lifecycle.
>>- F

Re: [rspec] Question on implementing rspec test using concurrency with threads, etc.

[Myron Marston]

It's hard for me to answer your question because your code confuses so I'm
not sure what your intent is.  If you can update it to be a little more
concrete that would help.  Here's a few thoughts, though


   - It looks like you are trying to run an RSpec spec inside your
   `consume` method in a thread.  That's not going to work.  RSpec takes
   responsibility for running your specs at an appropriate time in the
   runner's lifecycle.
   - For this kind of logic, I find it works best to treat the
   threading/concurrency as an implementation detail that my tests are unaware
   of.  Instead, my test treats a bit of logic as a black box, invoking it via
   some public API and then making assertions after it completes about the
   return value or the produced side effects.  With this strategy, the
   threading would all be internal to your implementation, and in your spec
   you would just run a synchronous `perform_work` (or whatever) method that
   would do any threading stuff it wants internally, and then join the threads
   such that it doesn't return until the threads are complete.
   - If you're dealing with a problem that fits a producer/consumer
   pattern, consider using Ruby's Queue
    class.  It's threadsafe and
   makes communication between threads very easy.

HTH,
Myron

On Fri, Nov 13, 2015 at 6:41 PM, David Luu  wrote:

> Say I have a test design like below, for sample code, how should I
> structure it to get it working correctly within rspec? I'm still a relative
> novice to rspec and ruby. I know the way I've written the example code, the
> it test block is not valid and needs to be put in correct scope. But I'm
> not aware what's the best approach to restructure based on the intent of
> the test. As regular Ruby code, that should work fine, just not as an rspec
> test.
>
> To complicate matters more, the concurrency solution should be compatible
> with an rspec test of this kind of data driven design (unless you can
> provide an alternate data driven design approach to the linked example):
> http://stackoverflow.com/questions/31375083/structuring-a-csv-data-driven-test-with-rspec-the-basic-simple-way
>
> require 'rspec'
>
> describe "actual case scenario using concurrency in test process", :simple
> do
>
>   def produce_stuff
> # the code, note that this code itself is not Ruby specific
> # but rather Ruby library code or even like system shell calls
> # to call some infrastructure stuff that produces streaming data
>   end
>
>   def consume_and_validate_the_stuff
> # test validation code within this block
> it "description here" do
>   #consume/fetch the produced streaming live data, etc.
>   #then assert/validate the actual data/state against expected
>   expect(false).to eql(true)
> end
>   end
>
> =begin
> Test a scenario that requires performing some actions
> and concurrently validating the actions in tandem.
>
> Assume not possible to validate after the action as the data
> is processed live and not queued for test access after the fact,
> e.g. live streaming data in test environment with multiple consumers
> (besides the current test). And fetching that data as old archived data
> via offsets is problematic to get it right in sync (e.g. using the right
> offsets, etc.)
> =end
>   pt=Thread.new{produce_stuff()}
>   ct=Thread.new{consume_and_validate_the_stuff()}
>   pt.join
>   ct.join
>
> end
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/9ea305ef-7601-48c8-a691-dcf4ecc4e751%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmt7qvDsd%2BQ4LzkJnV9bmLG9t-Xds0rmiP%2BvuoqN%2Bu09Mg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] How to test an each loop on scope

[Myron Marston]

RSpec.describe User do
  describe ".some_method" do
it "calls #foo on each user returned by the `some_scope` scope" do
  users = [ instance_spy(User), instance_spy(User) ]
  allow(User).to receive(:some_scope).and_return(users)

  User.some_method

  expect(users).to all have_received(:foo)
end
  endend

This isn’t necessarily the best way to test this code. In a real system, I
might favor an integration test for this code depending on what the logic
of some_scope and foo are, whether or not they are tested elsewhere, etc —
but for an isolated unit test it’s about the best you can do.

HTH,
Myron
​


On Fri, Oct 30, 2015 at 2:44 AM, Mehmet BEYDOĞAN  wrote:

> I have the following code, how can I write unit test for this method? I
> want to make sure 'foo' method is getting called on users in a scope.
>
>   def self.some_method  users = User.some_scope  users.each do |user|
>  user.foo  endend
> Gist: https://gist.github.com/beydogan/8d6e01b68dcda0bb4d07
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/8f5ab842-e555-494d-8dbe-9c62cf094360%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsGu-0dS6gaLKAGMsakgYS9L_iyLn5UH6YTprFiKgFmQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Generating List Of Features and Examples

[Myron Marston]

The doc formatter is specifically intended to produce output that reads
like documentation when you’ve written your example group and example
descriptions with documentation in mind. The --dry-run flag allows you to
get the formatter output from your suite without actually running it — so rspec
--format doc --dry-run should provide you with a nice list of specs.

If the output of the documentation formatter isn’t to your liking, you can
implement your own formatter and use that instead.
​

On Mon, Oct 19, 2015 at 3:41 PM, Dylan Reichstadt <
dylan.reichst...@gmail.com> wrote:

> Does anyone know of built-in method or external gem that can take all of
> your suite's Features/Examples and generate them into a nicely formatted
> list?
>
> Someone asked me for a list of all of the rspec examples we have written.
>
> I guess I could run the test with the Documentation formatter and
> copy/paste, but I'm looking for a better way at generating docs.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/e8037fb4-d7b9-4915-9fd2-2896ca176ee4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmta8wLuxkjAAmyCsf%2B9cyJ6n3hWEqJBKrmoTSUCDv_C1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] My text in terminal turns invisible after typing rspec - why?

[Myron Marston]

I've never seen this behavior from RSpec (and have never heard a user
report it before).  RSpec doesn't do anything special with the terminal,
either.  Perhaps it has to do with something with your environment?  You
might try launching a terminal session with a stock bash profile and see if
the problem goes away -- if so, it would point to something in your bash
profile causing the problem.

HTH,
Myron

On Wed, Oct 14, 2015 at 8:49 AM, Tinmanic  wrote:

> After I run rspec several times in my Mac's Terminal by typing "rspec", I
> can no longer see the text I'm typing. In order to see the text again, I
> have to either open a new Terminal window or type "stty echo".
>
> Why does the text turn invisible, and how can I make it stop doing that?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/e4cc5de8-059b-4b2f-9946-4386fa98fb38%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmv2Pj4LuH%3DTm5tFUce%2BKD%2BXf1OkwkLWPogAu3x7EqkBVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] rails lib/* path in rspecs

[Myron Marston]

In Ruby, if you have a class Foo::Bar definition, it will fail with an
error like the one you received if Foo has not already been defined. That’s
simply how Ruby works and has nothing to do with RSpec. The solution is to
change your class definition to:

module Backup
  class Status
# ...
  endend

(Note: that could be class Backup if that’s what you intend it to be.)

Alternately, if you want to keep the class Backup::Status form, you’ll have
to require another file that does define the bare Backup class or module.
Typically this require would go at the top of your lib/backup/status.rb
file.

HTH,
Myron
​

On Sat, Sep 26, 2015 at 10:56 AM, Igor Yurchenko 
wrote:

> Thank you for answer. The adding "require 'backup/status'" causes error in
> lib/backup/status.rb:
>
> 20:14:54 - INFO - Running: spec/lib/backup/status_spec.rb
> Coverage report generated for RSpec to
> /home/space/devel/sole/sola/coverage. 1 / 7 LOC (14.29%) covered.
> /home/space/devel/sole/sola/lib/backup/status.rb:1:in `':
> uninitialized constant Backup (NameError)
> from
> /home/space/devel/sole/sola/spec/lib/backup/status_spec.rb:2:in `require'
> from
> /home/space/devel/sole/sola/spec/lib/backup/status_spec.rb:2:in ` (required)>'
>
> lib/backup/status.rb contains:
>
> class Backup::Status
> ...
> end
>
> I have supposed gem rspec_rails is responsible for similar kind of
> problem. But...
>
> I would be very gratefull for any ideas how to solve this problem...
>
>
> суббота, 26 сентября 2015 г., 17:14:31 UTC+3 пользователь Myron Marston
> написал:
>>
>> RSpec does not do any constant autoloading so if you're getting and
>> uninitialized constant error but the constant is defined in a file, it
>> means that file hasn't been loaded yet.  The simple solution is to
>> `require` the file.
>>
>> HTH,
>> Myron
>>
>> On Sat, Sep 26, 2015 at 4:46 AM, Igor Yurchenko 
>> wrote:
>>
>>> Hi, ppl...
>>>
>>> I need help with setting up rails evironment for rspec. I've created
>>> some code on lib/backup/status.rb path and matched specs at
>>> spec/lib/backup/status_spec.rb.
>>>
>>> The problem is the spec does not see Backup::Status constant defined at
>>> lib/backup/status.rb...
>>>
>>>
>>> Row "RSpec.describe Backup::Status do end" in spec/lib/backup/status.rb
>>> causes error:
>>> /home/space/devel/sole/sola/spec/lib/backup/status_spec.rb:4:in `>> (required)>': uninitialized constant Backup (NameError)
>>>
>>> Thanks in advance...
>>>
>>> --
>>> 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/49a5a495-cc57-4906-b69f-b3589319cc7b%40googlegroups.com
>>> <https://groups.google.com/d/msgid/rspec/49a5a495-cc57-4906-b69f-b3589319cc7b%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/ccc09de7-a485-4ce4-a24c-7c6038df59c4%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/ccc09de7-a485-4ce4-a24c-7c6038df59c4%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmtMo6gv9tc0ybChB9CxnPEqSnfmEMQBnyZ8TS7j9Emo3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Contributing to documentation

[Myron Marston]

This has been discussed extensively before:

https://groups.google.com/forum/#!msg/rspec/bcDpKAXx0MQ/7adBw2mOxwkJ

On Fri, Sep 25, 2015 at 9:42 AM, Jason Fleetwood-Boldt  wrote:

> One thing I've never understood about rspec, and specifically the warning
> against using allow any instance of, is how to test code that creates
> objects that you will want to stub.
>
> Since the objects are not created in rspec (but instead inside the tested
> code), I can't stub them, so I often have to either use
> allow_any_instance_of or stub out the new method on the class to return
> doubles.
>
> I understand why allow_any_instance_of is code-smelly but I've never
> really seen a good approach to this.
>
>
>
>
>
> On Sep 25, 2015, at 10:23 AM, Myron Marston 
> wrote:
>
> The relish docs are kept under source in the repository for each gem under
> the features directory. The ones you mentioned are here:
>
>-
>
> https://github.com/rspec/rspec-mocks/blob/master/features/old_syntax/any_instance.feature
>-
>
> https://github.com/rspec/rspec-mocks/blob/master/features/working_with_legacy_code/any_instance.feature
>
> Please submit suggested doc changes as a PR to the repo.
>
> Thanks,
> Myron
> ​
>
> On Fri, Sep 25, 2015 at 2:18 AM, James Doyley  wrote:
>
>> Hi,
>>
>> I was looking at the docs, specifically
>> https://relishapp.com/rspec/rspec-mocks/docs/old-syntax/any-instance
>>
>> https://relishapp.com/rspec/rspec-mocks/docs/working-with-legacy-code/any-instance
>>
>> I agree that it's a design smell, but I want to suggest an example.  I
>> couldn't find out how to contribute to the documentation hence posting here.
>>
>> I was just thinking a better example as an alternative would be
>>
>> RSpec.describe User, type: :model do
>>   subject(:user){ User.new }
>>   before(:each) do
>> allow(user).to receive(:foo).and_return("bar")
>>   end
>>
>>
>>
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To post to this group, send email to rspec@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/rspec/a725b287-f0ac-4315-83ca-c4ab9c03ba05%40googlegroups.com
>> <https://groups.google.com/d/msgid/rspec/a725b287-f0ac-4315-83ca-c4ab9c03ba05%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/CADUxQmspk2-5i197tVPaR27qSq-0daK7EWd-im32qy3UT0CHog%40mail.gmail.com
> <https://groups.google.com/d/msgid/rspec/CADUxQmspk2-5i197tVPaR27qSq-0daK7EWd-im32qy3UT0CHog%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> 
>
> Jason Fleetwood-Boldt
> t...@datatravels.com
> http://www.jasonfleetwoodboldt.com/writing
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/A0C13FEA-7B3A-43EB-86DF-B424622A7155%40datatravels.com
> <https://groups.google.com/d/msgid/rspec/A0C13FEA-7B3A-43EB-86DF-B424622A7155%40datatravels.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmu%3D0%2BTobfS%3Df8z%3DBzN3_AhATkAhEeTpMqd4Npx9XvkXrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] rails lib/* path in rspecs

[Myron Marston]

RSpec does not do any constant autoloading so if you're getting and
uninitialized constant error but the constant is defined in a file, it
means that file hasn't been loaded yet.  The simple solution is to
`require` the file.

HTH,
Myron

On Sat, Sep 26, 2015 at 4:46 AM, Igor Yurchenko 
wrote:

> Hi, ppl...
>
> I need help with setting up rails evironment for rspec. I've created some
> code on lib/backup/status.rb path and matched specs at
> spec/lib/backup/status_spec.rb.
>
> The problem is the spec does not see Backup::Status constant defined at
> lib/backup/status.rb...
>
>
> Row "RSpec.describe Backup::Status do end" in spec/lib/backup/status.rb
> causes error:
> /home/space/devel/sole/sola/spec/lib/backup/status_spec.rb:4:in ` (required)>': uninitialized constant Backup (NameError)
>
> Thanks in advance...
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/49a5a495-cc57-4906-b69f-b3589319cc7b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmvqj-vx1By8gxfhPbLQHCk7Ww3XCZ6w19hgU7GC4mweUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Contributing to documentation

[Myron Marston]

The relish docs are kept under source in the repository for each gem under
the features directory. The ones you mentioned are here:

   -
   
https://github.com/rspec/rspec-mocks/blob/master/features/old_syntax/any_instance.feature
   -
   
https://github.com/rspec/rspec-mocks/blob/master/features/working_with_legacy_code/any_instance.feature

Please submit suggested doc changes as a PR to the repo.

Thanks,
Myron
​

On Fri, Sep 25, 2015 at 2:18 AM, James Doyley  wrote:

> Hi,
>
> I was looking at the docs, specifically
> https://relishapp.com/rspec/rspec-mocks/docs/old-syntax/any-instance
>
> https://relishapp.com/rspec/rspec-mocks/docs/working-with-legacy-code/any-instance
>
> I agree that it's a design smell, but I want to suggest an example.  I
> couldn't find out how to contribute to the documentation hence posting here.
>
> I was just thinking a better example as an alternative would be
>
> RSpec.describe User, type: :model do
>   subject(:user){ User.new }
>   before(:each) do
> allow(user).to receive(:foo).and_return("bar")
>   end
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/a725b287-f0ac-4315-83ca-c4ab9c03ba05%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmspk2-5i197tVPaR27qSq-0daK7EWd-im32qy3UT0CHog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] [rspec-mocks] Proposed change: Make *and_call_original* the default behavior for *receive*

[Myron Marston]

Thanks for the suggestion! I agree with Jon, though, for a couple reasons:

   - Consistency: currently the default behavior is the same for expect and
   allow against *all* types of test doubles (including partial doubles).
   Changing the default behavior for one specific situations (using expect
   on a partial double) is, IMO, quite confusing. Consider, for example, this
   bit of code: expect(foo).to receive(:bar); foo.bar. If we made the
   change, what would it do? It would depend on what foo was, which might
   not be obvious from looking at the example in isolation (foo might be
   provided by a helper method defined in a module in a separate file or
   something).
   - Safer: in many cases, people are mocking or stubbing a method to
   prevent it from doing something they don’t want to happen in a test. If the
   default was and_call_original, it would surprisingly do the thing they
   are trying to prevent, which could have dangerous consequences. This would
   especially be a problem with long time RSpec users who expect the existing
   behavior and aren’t aware of the change.
   - Inertia: this would be a massive breaking change for most folks and
   for every person who wants this change (like yourself) I expect we’d have
   at least 2 who would be against it.

Myron
​

On Mon, Sep 14, 2015 at 7:01 PM, Jon Rowe  wrote:

> Personally, given than spec-mocks is primarily intended for creating test
> doubles and stubbing objects I feel this would be a perverse default, in
> the limited cases where stubbing a real object is a good idea you almost
> never want this to happen, I can kind of see this sort of behaviour might
> be expected in rspec-expectations but I don’t feel like it should be the
> default in mocks.
>
> Remember that the majority of `expect(something).to receive` calls are
> going to be in cases where something is a double and has no real behaviour
> in the first place.
>
> Jon Rowe
> ---
> m...@jonrowe.co.uk
> jonrowe.co.uk
>
> On Tuesday, 15 September 2015 at 11:49, Brian John wrote:
>
> I've been using rspec for a few years now and one thing has bothered me
> since the switch to the new *expect* syntax. For partial mocks, when
> using allow/expect(something).to receive... it reads more like a spy to
> me than a stub. Using an example from the README:
>
> expect(Person).to receive(:find)
>
> Reading this like a sentence, I would expect *Person* to receive a call
> to *find*...and that's it. Nothing in the above indicates to me that the
> *find* method should also be stubbed. The stub behavior seems like a side
> effect.
>
> My proposal would be to change the default behavior of *receive* so that
> *and_call_original* is the default behavior. An additional method could
> be added to to trigger the stub behavior. So the equivalent behavior for
> the above example would read something like this:
>
> expect(Person).to receive(:find).and_stub
>
> Obviously making this change would be relatively painful in that:
> * some may not agree that this is the correct behavior
> * those that are used to the prior behavior would have to get used to the
> new behavior
> * it would break a lot of existing tests
>
> Given the above I wanted to post here to see how others felt before
> submitting a pull request. My apologies if this has already been discussed,
> I did a search of the issues in the rspec-mocks repository and this forum
> and I couldn't find anything.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/8d5d5525-5749-4284-b8d7-e38833758d13%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/E66977996C89404F837AD40B422F324A%40jonrowe.co.uk
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this di

Re: [rspec] Generating Examples on the Fly

[Myron Marston]

If you just want to leverage RSpec's example lifecycle, and don't care to
make each property example tracked by RSpec as a separate example, I think
there's a pretty simple way to do this.  RSpec's example lifecycle is
primarily implemented simply by running each example in the context of a
new instance of the example group class -- that way, each example has a
clean slate to work with and instance variables from one example don't leak
into another.  Constructs like `let` in turn simply use an instance
variable under the covers to provide a per-example lifecycle.  So, here's
what you can do...

Instantiate a new instance of the example group class.  Here's where we do
it:

https://github.com/rspec/rspec-core/blob/v3.3.2/lib/rspec/core/example_group.rb#L557

<https://github.com/rspec/rspec-core/blob/v3.3.2/lib/rspec/core/example_group.rb#L557>
Then pass it (along with the reporter) to `Example#run` to run the example
in the context of the provided instance:

https://github.com/rspec/rspec-core/blob/v3.3.2/lib/rspec/core/example.rb#L189

Bear in mind that `Example#run` is not a public API so per our current
versioning policy it could be changed in any release (even a patch
release).  However, if you try building something with that API, find it
useful, and would like us to declare it public (such that it would only
change in major versions if ever), let us know -- I think we could do that.

HTH,
Myron



On Tue, Sep 1, 2015 at 4:47 AM, Allen Madsen 
wrote:

> This may not be exactly what you want, but you could generate the spec
> files and then shell out to rspec to run it. You'd probably then tell
> rspec to use a custom formatter and have it fail on first failure. The
> exit code would tell you if it passed and the output to stdout could
> be captured to read in any metadata necessary to decide what to do
> next.
> Allen Madsen
> http://www.allenmadsen.com
>
>
> On Mon, Aug 31, 2015 at 11:00 PM, Rob Howard  wrote:
> > Hello,
> >
> > Thanks for the reply. :-)
> >
> > Specifically regarding:
> >> However, I think you’ll have better success if you model each property
> as
> >> a
> >> separate RSpec example, and then have that RSpec example delegate to a
> bit
> >> of
> >> code you’ve written that dynamically generates and runs as many
> assertions
> >> as
> >> necessary against as many input examples as necessary — and then reports
> >> the
> >> results back to RSpec in the form of no exception (if the property
> passed
> >> all
> >> checks) or an exception with a good, detailed message if the property
> >> failed a
> >> check.
> >
> > Understood. That's pretty much how you'd use, say, Rantly. For example:
> >
> >   specify "+ and - reverse each other" do
> > property_of {
> >   integer
> > }.check { |n|
> >   expect(n + 1 - 1).to eq n
> > }
> >   end
> >
> > That's fine and all (neatened up so you have a shortcut with, say,
> property
> > "+ and - ..."  or something), but the thing I was really hoping to keep
> was
> > the running of the before and after hooks after each property test.
> >
> > At the moment, as soon as you try something with ActiveRecord in a way
> that
> > hits the database, you then only get the benefit of your existing "RSpec
> > Example lifecycle" before and after the entire run of properties. Same
> with
> > any setup for Rack testing, for example.
> >
> > (I *could* come up with my own mini-DSL that'd let you specify
> before/after
> > property runs, with the existing before/after(:each) acting effectively
> as
> > before(:all) for the properties, but I was very much hoping to avoid
> > something like that.)
> >
> > Thanks again,
> > Rob
> >
> >
> >
> >
> > On Tue, Sep 1, 2015 at 4:56 AM, Myron Marston 
> > wrote:
> >>
> >> Hey Rob,
> >>
> >> Sounds like an interesting, useful project!
> >>
> >> Dynamically generating examples works fine as long as they are all
> >> generated during the “load spec files” phase, before the first spec
> runs.
> >> Defining additional examples while the examples run isn’t going to work
> very
> >> well. A lot of RSpec’s features (e.g. randomization and metadata
> filtering)
> >> need to be able to get the complete list of examples before the first
> one
> >> runs so that these features can do their thing. In addition, other
> features
> >> in 3.3 (bisect and —only-failures) rely the example IDs being stable —
> that

Re: [rspec] Generating Examples on the Fly

[Myron Marston]

Hey Rob,

Sounds like an interesting, useful project!

Dynamically generating examples works fine *as long as they are all
generated during the “load spec files” phase, before the first spec runs*.
Defining additional examples while the examples run isn’t going to work
very well. A lot of RSpec’s features (e.g. randomization and metadata
filtering) need to be able to get the complete list of examples *before*
the first one runs so that these features can do their thing. In addition,
other features in 3.3 (bisect and —only-failures) rely the example IDs
being stable — that is, spec/foo_spec.rb[1:10] needs to consistently
reference the same example (in this case, the 10th example in the 1st
example group in spec/foo_spec.rb) on each run of the suite to work
properly. If you are generating additional examples as the specs run the
ids may not be consistent and you’re going to break some of RSpec’s
features.

My suggestion is to change how you model the problem. From what you
described, you are modeling each assertion as a separate RSpec example.
This is natural, given that each assertion represents an example of the
property being verified and RSpec has something called an example as well.
However, I think you’ll have better success if you model each property as a
separate RSpec example, and then have that RSpec example delegate to a bit
of code you’ve written that dynamically generates and runs as many
assertions as necessary against as many input examples as necessary — and
then reports the results back to RSpec in the form of no exception (if the
property passed all checks) or an exception with a good, detailed message
if the property failed a check.

Does that make sense?

BTW, I’m leaving for a long vacation tonight and will have sporadic access
to email so I may not see or respond to replies for quite some time. I’m
sure others can help out, though :).

HTH,
Myron
​

On Sun, Aug 30, 2015 at 4:05 PM, Rob Howard  wrote:

> Hello,
>
> I'm looking to write a library that adds property-based testing to RSpec,
> in the style of QuickCheck[1].
>
> The particular difficulties of this integration is that there there are a
> number of repeated tests, these tests being generated or cut short on the
> fly, as opposed to being all being generated in advance.
>
> For example, when testing that a sorting function works correctly (eg.
> [3,1,2].my_sort == [1,2,3]), I'd generate 100 tests with different arrays
> of items in ever-increasing sizes. If one of the tests were to fail, I'd
> want to stop running further tests, and then swap over to a separate
> "shrinking" phase where I generate further tests with the failing output
> until I can get the smallest input I can generate to fail the example.
>
> The test runs could look like (each line being an input, and an output of
> a test run with its result):
>
>   Initial run (up to 100 attempts):
>   [] == [], Passed
>   [1] == [1], Passed
>   [2,1] == [1,2], Passed
>   [2,1,9,4,5,5,6,7] == [1,2,4,5,6,7,9], Failed! Stopping here; no further
> data generation to be done.
>
>   Shrinking failed value...
>   [2,1,9,4,5,5,6] == [1,2,4,5,6,9], Failed
>   [2,1,9,4,5,5] == [1,2,4,5,9], Failed
>   [2,1,9,4,5] == [1,2,4,5,9], Passed
>
>   Failed, with smallest known failing value: [2,1,9,4,5,5]
>
> To do the above with RSpec means being able to, in either an around()
> block or in an example itself, add further examples to an example group to
> run, on the fly. This doesn't appear to be possible. Even directly
> monkeying with an example.example_group.examples list is already too late;
> nothing picks up the change.
>
> I've had the suggestion of having the ExampleGroup examples be an iterator
> instead of a plain list. Would I be on the right track there, or does
> anyone have any other suggestions?
>
> (I'm particularly interested in an RSpec integration so as to take
> advantage of the existing test integrations people have, eg. database
> resets for ActiveRecord models, Capybara Rack-based tests, etc. There are
> other Quickcheck ports/adaptations (eg. Rantly[2], Rubycheck[3],
> Queencheck[4]), yet none of them have this RSpec lifecycle integration; the
> only thing that *does* is Generative[5], which just replicates single
> examples a certain number of times, with none of the early-stop or
> shrinking smarts that I'm trying to implement.)
>
> Thanks,
> Rob
>
> 1.
> https://www.fpcomplete.com/user/pbv/an-introduction-to-quickcheck-testing
> 2. https://github.com/hayeah/rantly
> 3. https://github.com/mcandre/rubycheck
> 4. https://github.com/rosylilly/QueenCheck
> 5. https://github.com/justincampbell/generative
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/CA

Re: [rspec] “undefined method 'allow'” after following deprecation instructions

[Myron Marston]

If allow is not defined, it means that RSpec::Mocks::ExampleMethods hasn’t
been included in that context. I believe the fix would be:

World(RSpec::Mocks::ExampleMethods)

…but I haven’t written a cucumber hook in a long time.

One general question: why are you trying to unstub a method in an After
hook? The lifecycle used by rspec-mocks is per example (i.e. per scenario
in a cucumber context), assuming you’ve set it up correctly, so all stubs
will be removed after each scenario anyway.

HTH,
Myron
​

On Mon, Jul 27, 2015 at 8:51 AM, Grant Birchmeier  wrote:

> In my cucumber hooks file, I had this code under RSpec 2:
>
> After do
>   begin
> Challenge.unstub(:current)
>   rescue RSpec::Mocks::MockExpectationError
>   end
> end
>
>
> After upgrading to RSpec 3, I get a deprecation warning:
>
> DEPRECATION: Using unstub from rspec-mocks' old :should syntax without
> explicitly enabling the syntax is deprecated. Use
> allow(...).to_receive(...).and_call_original or explicitly enable :should
> instead. Called from /Users/grant/xx/features/support/hooks.rb:37:in block
> in .
>
>
> So I followed that, changing the offending line instead to:
>
> allow(Challenge).to receive(:current).and_call_original
>
>
> But now I get:
>
> undefined method allow for #
> (NoMethodError)
>
>
> I've tried adding "include RSpec::Matchers" a few different ways, but it
> doesn't change anything.
>
> I'm kind of stuck.  Can anyone show me the way?
>
> -Grant
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/1dbbcdc2-d996-4d8a-b03f-5a8f6b1073a4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQms-cRxQ-ZxoMBc90ZsLt8M5xOewG%3D-ry4Gj-ZLrSbU2%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Catching Exceptions Across Suite

[Myron Marston]

Rescuing exceptions in an around hook won’t work because within example.run
RSpec rescues the exception as part of tracking the example state,
notifying formatters, etc.

Are you looking to track *all* raised exceptions (even if something rescues
them and/or retries)? Or just all the example failure exceptions?

If you’re looking for the former, you’ll probably have to monkey patch
Kernel#raise or use a tracepoint
.

If you’re looking for the latter, you can implement a listener/formatter
that registers the :example_failed event with RSpec so that it is notified
every time an example fails, and then you can do whatever you want when
notified.

HTH,
Myron
​

On Wed, Jul 22, 2015 at 7:20 PM, Dylan Reichstadt 
wrote:

> Hey Jon,
>
> Pretty solid idea! I didn't think of this.
>
> Unfortunately it doesn't look to catch the exception though. Tested
> with RSpec::Expectations::ExpectationNotMetError
>
> This was a snippet of my code (which never printed 'In here!' when the
> exception was raised - I tried simply rescue Exception as well):
>
> RSpec.configure do |config|
>   config.around(:each) do |example|
> begin
>   example.run
> rescue RSpec::Expectations::ExpectationNotMetError
>   puts 'In here!'
>   raise
> end
>   end
> end
>
>
>
>
>
> On Wednesday, July 22, 2015 at 6:11:44 PM UTC-7, Jon Rowe wrote:
>>
>> Not specifically, but you can configure an around hook to do what you
>> want:
>>
>> Rspec.configure do |config|
>>   config.around(:example) do |example|
>> begin
>>   example.run
>> rescue Net::ReadTimeout
>>   # … your code
>>   raise
>> end
>>   end
>> end
>>
>> Jon Rowe
>> ---
>> ma...@jonrowe.co.uk
>> jonrowe.co.uk
>>
>> On Thursday, 23 July 2015 at 11:06, Dylan Reichstadt wrote:
>>
>> Hey All,
>>
>> I am looking to add better instrumentation around exceptions thrown in
>> rspec. For example, I want to track how many times I get a Net::ReadTimeout
>> error from Capybara/Rspec.
>>
>> In a limited scope, I have been:
>>
>>- Rescuing this exception
>>- Incrementing a global variable
>>- Re-raising that exception again (after incrementing)
>>
>>
>> However, this exception can happen across all examples. I don't want to
>> wrap every scenario in a Begin & Rescue block - that sounds extremely messy.
>>
>> Does rspec have something to help with this, or does anyone have any
>> ideas I can achieve better tracking of exceptions? I have been googling
>> around RSpec and Catching All Exceptions, but can't find anything.
>>
>> --
>> 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/88d51b4d-2bb3-4391-bffd-476663474a07%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>   --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/ad47b93c-b440-4591-9af5-98f49b0aad1f%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsRCWta2UZf9GCEf2a81BeFSHk4qFwJP7mDEyfGGR_0oQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] How to mock a class with Internet access, faking time-dependent content changes

[Myron Marston]

If you're not trying to record and replay real content, VCR is probably not
the right tool (thought it can be "bent" to fit your use case, as you
say).  I'd suggest that WebMock might fit your use case better:

https://github.com/bblimke/webmock

On Mon, Jun 29, 2015 at 12:34 AM, Juergen Schlinker <
schlinkerjuer...@gmail.com> wrote:

> I already had a quick look at VCR before.
> I always thought that it's best for replaying real http content.
> I am looking at faking web content dependent on the time.
> However, I might be able to "bend" VCR to suite my needs.
> Thanks for the suggestion!
>
>
> 2015-06-26 17:10 GMT+02:00 Myron Marston :
>
>> On Fri, Jun 26, 2015 at 3:02 AM, JSchlinker 
>> wrote:
>>
>>> I am using Rspec to test a module that has an external dependency with
>>> the Internet.
>>> This is why I am trying to mock out the class that handles the actual
>>> access of the webpage when running my tests.
>>>
>>> My class "Snapshot" (that I want to test) accesses a webpage when it is
>>> requested and will save the html in a file when the hash of the content has
>>> changed.
>>> The filename should have a certain name according to the date/time and a
>>> running number.
>>> And there should be a log message when an error occours (e.g. no
>>> Internet or website down), containing the status code (e.g. 404).
>>>
>>> I made some basic tests, but now wanted to write a test integrating a
>>> couple of classes.
>>> The only thing that I would like to mock is the Internet part.
>>> As the snapshots are only generated when the html content changes I
>>> thought about the following approach:
>>>
>>> - Use timecop to fake a time and be able to check if the saved filename
>>> corresponds to this date/time
>>> - Mock the class "Internet" by specifying certain time spans in which
>>> the class should return a certain content
>>>
>>> My class under test looks like this:
>>>
>>> class Snapshot < ActiveRecord::Base
>>>
>>>  def self.grab_website(uri)
>>>  response, content = Internet.access_webpage(uri)
>>>  # code that calculates the hash, saves the content or
>>> generates an error log messages
>>>   end
>>>
>>> end
>>>
>>>
>>> My Rspec "preparation code" for mocking the class Internet looks like
>>> this:
>>>
>>> stub_const("Internet::WEBSITE_REPLIES", \
>>> { "http://www.thiswebsiteisimportanttome.com"; => \
>>> [["2015-06-12 15:30", "website_Version_A.html"] ,\
>>>  ["2015-06-14 18:00", "website_Version_B.html"] ,\
>>>  ["2015-06-14 18:50", 404] ,\
>>>  ["2015-06-14 19:00", "website_Version_C.html"] ,\
>>>  ["2015-06-26 11:35", "website_Version_D.html"]] } )
>>>
>>>  allow(Internet).to receive(:access_webpage) do |uri|
>>> time = Time.now
>>> content = nil
>>> response_code = 0   # We're not connected to the
>>> internet
>>>
>>> if Internet::WEBSITE_REPLIES.has_key?(uri)
>>> filename = nil
>>> timetable = Internet::WEBSITE_REPLIES[uri]
>>> timetable.each do |timepoint_situation|
>>> timepoint = Time.parse(timepoint_situation[0])
>>> if time > timepoint
>>> filename = timepoint_situation[1]
>>> end
>>> end
>>> if (filename.nil?)
>>> response_code = 0
>>> elsif (filename.kind_of? Integer)
>>> response_code = filename
>>> else # filename is really a filename
>>> content = File.read(filename)
>>> response_code = 200
>>> end
>>> end
>>> next response_code, content
>>> end
>>>
>>>
>>> And my actual test looks like this:
>>>
>>> first_time = Time.local(2015, 6, 12, 15, 35)
>>> second_time = Time.local(2015, 6, 14, 17, 00)
>>> third_time = Time.local(2015, 6, 14, 18, 05)
>>>
>>> uri = "http://www.thiswebsiteisimportanttome.com";
>>> Timecop.freeze(first_time) # Version A
>>> Snapshot.grab_website(uri)
>>>

Re: [rspec] How to mock a class with Internet access, faking time-dependent content changes

[Myron Marston]

On Fri, Jun 26, 2015 at 3:02 AM, JSchlinker 
wrote:

> I am using Rspec to test a module that has an external dependency with the
> Internet.
> This is why I am trying to mock out the class that handles the actual
> access of the webpage when running my tests.
>
> My class "Snapshot" (that I want to test) accesses a webpage when it is
> requested and will save the html in a file when the hash of the content has
> changed.
> The filename should have a certain name according to the date/time and a
> running number.
> And there should be a log message when an error occours (e.g. no Internet
> or website down), containing the status code (e.g. 404).
>
> I made some basic tests, but now wanted to write a test integrating a
> couple of classes.
> The only thing that I would like to mock is the Internet part.
> As the snapshots are only generated when the html content changes I
> thought about the following approach:
>
> - Use timecop to fake a time and be able to check if the saved filename
> corresponds to this date/time
> - Mock the class "Internet" by specifying certain time spans in which the
> class should return a certain content
>
> My class under test looks like this:
>
> class Snapshot < ActiveRecord::Base
>
>  def self.grab_website(uri)
>  response, content = Internet.access_webpage(uri)
>  # code that calculates the hash, saves the content or generates
> an error log messages
>   end
>
> end
>
>
> My Rspec "preparation code" for mocking the class Internet looks like
> this:
>
> stub_const("Internet::WEBSITE_REPLIES", \
> { "http://www.thiswebsiteisimportanttome.com"; => \
> [["2015-06-12 15:30", "website_Version_A.html"] ,\
>  ["2015-06-14 18:00", "website_Version_B.html"] ,\
>  ["2015-06-14 18:50", 404] ,\
>  ["2015-06-14 19:00", "website_Version_C.html"] ,\
>  ["2015-06-26 11:35", "website_Version_D.html"]] } )
>
>  allow(Internet).to receive(:access_webpage) do |uri|
> time = Time.now
> content = nil
> response_code = 0   # We're not connected to the internet
>
> if Internet::WEBSITE_REPLIES.has_key?(uri)
> filename = nil
> timetable = Internet::WEBSITE_REPLIES[uri]
> timetable.each do |timepoint_situation|
> timepoint = Time.parse(timepoint_situation[0])
> if time > timepoint
> filename = timepoint_situation[1]
> end
> end
> if (filename.nil?)
> response_code = 0
> elsif (filename.kind_of? Integer)
> response_code = filename
> else # filename is really a filename
> content = File.read(filename)
> response_code = 200
> end
> end
> next response_code, content
> end
>
>
> And my actual test looks like this:
>
> first_time = Time.local(2015, 6, 12, 15, 35)
> second_time = Time.local(2015, 6, 14, 17, 00)
> third_time = Time.local(2015, 6, 14, 18, 05)
>
> uri = "http://www.thiswebsiteisimportanttome.com";
> Timecop.freeze(first_time) # Version A
> Snapshot.grab_website(uri)
>
> Timecop.freeze(second_time) # Version A (no changes)
> Snapshot.grab_website(uri)
>
> Timecop.freeze(third_time) # Version B
> Snapshot.grab_website(uri)
>
> snapshots = Snapshot.all
> expect(snapshots.size).to eq(2)
>
> snapshot = snapshots[0]
> expect(snapshot.time).to eq(first_time)
> expect(snapshot.hash).to eq("234092384EF")
> expect(snapshot.filename).to eq(...)
>
> snapshot = snapshots[1]
> expect(snapshot.time).to eq(third_time)
> expect(snapshot.hash).to eq("A8E92340213")
> expect(snapshot.filename).to eq(...)
>
> # work to do: check the log messages ...
>
>
> I have the feeling that there should be an easier way to do this.
> Especially because I can't imagine that I'm the only one that wants to
> test time dependent Website content.
> I am grateful for any suggestions!
>
> J.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/c1ed74fa-8f54-40ae-a6ba-ccfab2584bc1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

Take a look at VCR . It is specifically
designed for when you are testing HTTP-dependent code.
​

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this disc

Re: [rspec] How to stub class and instance methods of the same class using rspec/rspec-mocks

[Myron Marston]

Would I first mock the object using

book_object = double("Book")
allow(book_object).to receive(:read_page).and_return(...)

 That certainly works, but I have two suggestions:

   - Use instance_double("Book") instead of double("Book"). The latter is
   not a verifying double, which means it does nothing to warn you when the
   interface of your test double and that of Book instances diverge.
   - Since you don’t appear to care about the arguments, you can in-line
   the stub as part of the test double definition:

book_object = instance_double("Book", read_page: page_value)

 and then mock the class by

book = class_double("Book")
allow(book).to receive(:new).and_return(book_object)

 Again, you can inline the new stub:

book = class_double("Book", new: book_object)

Actually, you could inline it all into one line:

book = class_double("Book", new: instance_double("Book", read_page: page_value))

That said, neither your snippet nor this one-line will work for the code
snippet you pasted, because your snippet directly references the Book
constant.

One solution is to change the code under test to accept an injectable
book_factory argument (which can have a default value of Book but in your
test you can pass the class double for it). This makes has all the benefits
of dependency injection (makes the dependency explicit in the method
signature, supports additional flexibility by allowing the caller to pass a
different book implementation, etc) while having all the downsides of
dependency injection (added code, an additional argument that is just there
to support testing, YAGNI, etc).

Another approach is to chain as_stubbed_const off your class_double:

class_double("Book", new: instance_double("Book", read_page:
page_value)).as_stubbed_const

This will cause the Book constant to be defined (or replaced) for the
duration of the example as your class double, so that any code that
references the Book constant will get your test double rather than the real
Book class and/or an “undefined constant” error.

A third approach is to define your Book class and stub the new method on
that directly…but it sounds like you are wanting to avoid defining it so
one of the first two approaches better fits the workflow you are aiming
for, I think.

HTH,
Myron
​

On Thu, Jun 25, 2015 at 3:21 AM, JSchlinker 
wrote:

> I am using rspec-mock for test-driven-development.
>
> I am starting implementing a single class and mocking/stubbing the other
> classes using rspec-mock. Mocking only objects of classes yet to be
> implemented works well. However when I try to mock a class method and
> instance methods for objects of the same class I am not sure how the
> preferred way to do this looks like.
>
> I have code that e.g. looks like this:
>
> new_book = Book.new
> content = new_book.read_page(5)
>
> I now want to mock out everything that has to do with the class "Book". In
> this example this would mean "Book.new" and "new_book.read_page"
>
> Would I first mock the object using
>
> book_object = double("Book")
> allow(book_object).to receive(:read_page).and_return(...)
>
> and then mock the class by
>
> book = class_double("Book")
> allow(book).to receive(:new).and_return(book_object)
>
>
> Is this the way to go?
>
>  --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/0690a743-805e-410a-ba9d-2bc2a2ea930e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmuYwv8wrqbUkJX3nkJPzQX4JZN34ktxcXcgiHUx9p5koA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[rspec] Re: Writing first Rspec

[Myron Marston]

On Thursday, June 25, 2015 at 12:27:14 AM UTC-7, Aravindhan A wrote:
>
> Hello,
>
> I have come up with the following code.  It involves checking a sentence 
> with some conditions.  I am in need of writing a RSpec for this particular 
> file.
>
> Class Sentence
> def test(sen)
>
> first = sen[0]
> last = sen.split('').last
> rest = sen[1..-1]
> word_arr = sen.split
> word_arr_len = word_arr.length
>
> unless first == first.upcase then
> puts "The first letter is not in uppercase"
> end
>
> if  word_arr_len == 1 then
> puts "There must be spaces between words"
> end
>
> unless last == "." || last = last.upcase then
> puts "The sentence should end with a full stop"
> end
>
> unless (sen =~ /[A-Z]{2,}/) == nil then
> puts "No two consecutive upper case letters are allowed"
> end
>
> unless sen == word_arr.join(" ")  then
> puts "No two consecutive spaces are allowed"
> end
> end
> end
>
>
> #test("Simple sentence.")
>
> I want to write a simple RSpec code that passes a value to the test method 
> [Similar to the last commented line].  Kindly help me out!
>
> Thanks in advance.
>

The `output` matcher will work well here.  I've put together the start of 
what the specs could be:

https://gist.github.com/myronmarston/a553f22ce5f2a7d058ec

This includes one spec for the "happy path" case (where it passes all 
checks and prints nothing) and one spec for one of the validations.  You 
should be able to follow the example to come up with specs for the other 
validations.

HTH,
Myron

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/ea07095d-bb8f-4fd6-a93a-9dc03b427f8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rspec] Re: Unable to print STDOUT Ruby

[Myron Marston]

Please provide code inline or via links to gist.github.com (or a similar
service) rather than providing photos.

Anyhow, the `command` method isn't part of core RSpec.  Whatever library
you are using that provides that probably provides a way to get the stdout
of running that command.  You'll have to check with the docs or project
maintainers on that.

Myron

On Wed, Jun 24, 2015 at 11:49 AM, Laurence Rosenzweig 
wrote:

> Thanks for the reply. I had seen that a few days ago but didn't think it
> was helpful...perhaps I did not use it correctly. It felt like whatever I
> wrote, it just approved. Basically I have a command I am running and I want
> to see what it's stdout is to see for some of my tests why it is not
> matching my expectation. See attached image for what I am trying to do.
>
>
> On Wednesday, June 24, 2015 at 1:42:57 PM UTC-4, Myron Marston wrote:
>>
>> On Wednesday, June 24, 2015 at 6:18:02 AM UTC-7, Laurence Rosenzweig
>> wrote:
>>>
>>>
>>>
>>> On Wednesday, June 24, 2015 at 9:14:58 AM UTC-4, Laurence Rosenzweig
>>> wrote:
>>>>
>>>> I have been running Rspec tests and want to print out STDOUT. It seems
>>>> like a very simple problem yet I see very little documentation about this
>>>> issue and I have been unable to figure out how to print it. I know as a
>>>> variable you can do $stdout but whenever I print it (using pp, puts, or
>>>> print), I cannot get the actual value of stdout.
>>>>
>>>>
>>>>
>>>> I attached an image of one of my tests with a few of my different
>>>> attempts (commented out at the moment).
>>>>
>>>>
>>>>
>>>> Thanks for your help!
>>>>
>>>
>>
>> Ruby's `$stdout` doesn't provide you with what has been written to
>> stdout.  It's an IO object that can be written to but not read from.  If
>> you want to set an expectation about what has been written to stdout, we
>> have a matcher for that:
>>
>>
>> https://relishapp.com/rspec/rspec-expectations/v/3-3/docs/built-in-matchers/output-matcher
>>
>> HTH,
>> Myron
>>
>>
>>
>  --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to rspec@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/f2b776fa-011b-4ddb-ba37-0be4025d3e85%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/f2b776fa-011b-4ddb-ba37-0be4025d3e85%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/CADUxQmsBOPyW82dCu6Q9734qFjYAHh3Bn%3DA55yaBMxi2%3DALMjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[rspec] Re: Unable to print STDOUT Ruby

[Myron Marston]

On Wednesday, June 24, 2015 at 6:18:02 AM UTC-7, Laurence Rosenzweig wrote:
>
>
>
> On Wednesday, June 24, 2015 at 9:14:58 AM UTC-4, Laurence Rosenzweig wrote:
>>
>> I have been running Rspec tests and want to print out STDOUT. It seems 
>> like a very simple problem yet I see very little documentation about this 
>> issue and I have been unable to figure out how to print it. I know as a 
>> variable you can do $stdout but whenever I print it (using pp, puts, or 
>> print), I cannot get the actual value of stdout.
>>
>>  
>>
>> I attached an image of one of my tests with a few of my different 
>> attempts (commented out at the moment).
>>
>>  
>>
>> Thanks for your help!
>>
>

Ruby's `$stdout` doesn't provide you with what has been written to stdout. 
 It's an IO object that can be written to but not read from.  If you want 
to set an expectation about what has been written to stdout, we have a 
matcher for that:

https://relishapp.com/rspec/rspec-expectations/v/3-3/docs/built-in-matchers/output-matcher

HTH,
Myron

 

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to rspec@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rspec/4cb9c7f2-9525-409e-af3d-533f3eb71de2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.