We use DelayedJob to run some of our long running processes and would like to test with Cucumber/Webrat.
Currently, we are calling Delayed::Job.work_off in a Ruby thread to get work done in the background, but are looking for a more robust solution
What is the best approach for this?
Thanks.
The main problem I see with the Delayed:Job.work_off approach is that you are making explicit in your Cucumber scenarios something that belongs to the internals of your system. Mixing both concerns is against the spirit of functional testing:
When I click some link # Some operation is launched in the background
And Jobs are dispatched # Delayed:Job.work_off invoked here
Then I should see the results...
Another problem is that you populate your Cucumber scenarios with repetitive steps for dispatching jobs when needed.
The approach I am currently using is launching delayed_job in the background while cucumber scenarios are being executed. You can check the Cucumber hooks I am using in that link.
Related
Problem to solve: We want to be able to run multiple ruby cucumber tests in parallel with different users. Since we have user collision in the app, we are not able to use the same user simultaneously.
We tried looking into parallel_test gem to use parallel_cucumber but did not find any way to pass a different user for each process. One option I read online was to have user info in the DB and make a call to get a free user before each test. This was not feasible for us.
Does anyone know any way to make parallel_cucumber or any other ruby gem work to run parallel cucumber tests with a different user for each process
If you are running parallel tests you should be able to use a separate db for each stream. This should avoid the issue of user collisions.
Parallel execution of cucumber 4 work for me, but I want to execute some actions just once for all tests, It is a possible way to run some hooks in another Thread ?
As per your requirement, you want to execute some actions for all test cases once, is it like before or after all test case execution. If so then adding #BeforeClass from JUnit/TestNG and Similarly you can use #AfterClass in your run cuke class. This piece of code would run once before running your first class and after all test execution completed.
would it may work or adding tagged hooks give you some clue. Like for some specific test cases you can use tagged hooks and run those specific actions inside that hook only.
I don't have a lot of experience in Cakephp 2.0, but I want to create a shell that will call more tasks.
The idea is that I don't want to add many cron jobs but I would like to have more tasks.
The main question is if the tasks from a Shell are called asynchronously or synchronously.
It would be great if they are called asynchronously, but if not, what other solutions might there be for my problem?
Thanks.
UPDATE 1
I have tested and it's very clear that tasks called in a Shell are called and executed synchronously. How can I change this? I want to start more task in the same time from the same Shell.
The Queue plugin does pretty much exactly what you want.
Working with a Sinatra application, and found 3 ways to run a background process:
Thread.new
Process.fork
Process.spawn
Figured out how to get the first two to work, but now the challenge is that the tests need to run synchronously (for a few reasons).
What is a good way to run jobs asynchronously in production, but force the tests to run synchronously? Preferably with a call in the spec_helper...?
Ruby 1.9.3, Sinatra app, RSpec.
I recommend the following hybrid approach:
Write simple unit tests and refactor what you're testing to be synchronous. In other words, put all of the background functionality into straightforward classes and methods that can be unit tested easily. Then the background processes can call the same functionality, that's already been unit tested. You shouldn't have to unit test the background thread/process creation itself, since this is already tested in ruby (or another library like god, bluepill or Daemons. This TDD approach has the added benefit of making the codebase more maintainable.
For functional and integration tests, follow the approach of delayed_job and provide a method to do all of the background work synchronously, like with Delayed::Worker.new.work_off
You also may want to consider using EventMachine (as in Any success with Sinatra working together with EventMachine WebSockets? ) over spawning threads or processes, especially if the background processes are IO intensive (making http or database requests, for example).
Here's what I came up with:
process_in_background { slow_method }
def process_in_background
Rails.env == 'test' ? yield : Thread.new { yield }
end
def slow_method
...code that takes a long time to run...
end
I like this solution because it is transparent: it runs the exact same code, just synchronously.
Any suggestions/problems with it? Is it necessary to manage zombies? How?
In our development environment, we run a Continuous Integration service (TeamCity) which responds to code checkins by running build/test jobs and reporting the results. While the job is in progress, we can easily see how many unit tests have executed so far, how many have failed, etc.
My automated testing team is delivering UI tests developed in Rational Functional Tester. Extracting those tests from the source control system, compiling them, and executing them from the command line all seem to be pretty straight forward exercises.
What I haven't been able to find is a way to report the test results automatically - there don't appear to be any hooks for listeners, for example, or any way to customize the messages that are emitted.
From my research thus far, I've come to the conclusion that my only option is to (a) wait until the tests finish, then (b) parse the HTML report that RFT generates.
Does anybody have a better answer than that?
Here is the workaround I've used for the similar purpose:
Write a helper super class that overwrite the onTerminate callback method, implement your log parsing logics there.
Change the helper super class of your test scripts to the helper super class create in step1.
Use RFT CLI invoke your scripts in your Continous Integration code.
Expanding on #eric2323223, in your onTerminate override, you can use TeamCity's build script interaction functionality to have your RFT pass/fail status rolled up to TeamCity. You just need these TeamCity specific messages emitted to the command line, so that TeamCity picks them up.
##teamcity[testStarted name='test1']
##teamcity[testFailed name='test1' message='failure message' details='message and stack trace']
##teamcity[testFinished name='test1']
##teamcity[testStarted name='test2']
##teamcity[testFailed type='comparisonFailure' name='test2' message='failure message' details='message and stack trace' expected='expected value' actual='actual value']
##teamcity[testFinished name='test2']