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
   <http://ruby-doc.org/core-2.2.0/Queue.html> class.  It's threadsafe and
   makes communication between threads very easy.

HTH,
Myron

On Fri, Nov 13, 2015 at 6:41 PM, David Luu <[email protected]> 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 [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rspec/9ea305ef-7601-48c8-a691-dcf4ecc4e751%40googlegroups.com
> <https://groups.google.com/d/msgid/rspec/9ea305ef-7601-48c8-a691-dcf4ecc4e751%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 [email protected].
To post to this group, send email to [email protected].
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.

Reply via email to