I have a Sinatra app, overall configured like described here sinatra docs.
It basically starts an event machine loop.
Now, If I want to write a RSpec test, how do I start server like this and shutdown it after?
I can do this from console by ruby server.rb, I may execute this command from spec file in test suit setup (however, I'm not sure if it is right). But then, even if I do so, how I stop it after? (and do I need or it will be stopped after test is finished?)
I think, in any case, you can use Rack::Test to test your Sinatra app. In order to run the specs, you don't need to run the server from the terminal.
Take a look at the documentation, you can find different examples:
http://www.sinatrarb.com/testing.html
Related
I am trying to use RSpec to functional test my REST apis.
The way I would LIKE it to work is using a CI build to build and deploy my application to a test server somewhere in the cloud and then have it kick off automated functional tests. But in order to properly do that, I need to be able to pass in the base url/domain for where the app was deployed. It will not be the same.
Everything I've found so far makes it seem like RSpec can't do this. Is there another way to do it if I can't pass in parameters on the command line? Or is RSpec not the right choice for this?
One way would be to bypass the call to rspec with something that accepts command line arguments and then initiate rspec in code. If you do not want to write your own binary for that, rake is capable of that too.
Look here for how to run rspec from code.
Another way would be setting an ENV variable when calling your test and preferably making it optional in the specs.
$> SPEC_URL=http://anotherhost:666 rspec
in code:
url = ENV['SPEC_URL'] || "http://localhost:4000"
I would suggest method two as it's the cleaner and easier approach in my opinion.
I'm designing a web service using Sinatra and I need to perform certain operations when the service is started and some other operations when the server is stopped.
How can I register those operations to be fully integrated with sinatra?
Thanks.
The answer depends on how you need to perform your operations. Does they need to be ran for each ruby process or do they need to be ran just once for the service. I suppose it's once for all the service and in the case of the latest :
You might be tempted to run some code before your Sinatra app is starting but this is not really the behavior you might expect. I'll explain why just after. The workaround would be adding code before your sinatra class like
require "sinatra"
puts "Starting"
get "/" do
...
end
You could add some code to your config.ru too btw, would have the same effect but I don't which one is uglier.
Why is this wrong ? Because when you host your web service, many web server instances will be fired and each one will execute the puts method or your "starting" code. This is correct when you want to initialize things that are local to your app instance, like a database connection but not to initialize things which are shared by all of them.
And about the code firing at its end, well you can't (or maybe you could with some really ugly workaround, but you'll end with the same issue you get with the start).
So the best way to handle on and off operations would be to wrap it within your tasks firing your service.
Run some rake task or ruby script that do your initalization stuff
Start your web server
And to stop it
Run a rake task or ruby script that stops the server
Run your rake task or ruby script that does the cleaning operations.
You can wrap those into a single rake task, by starting your app server directly from ruby, like I did there https://github.com/TactilizeTeam/photograph/blob/master/bin/photograph.
This way you can easily add some code to get ran before starting the service, still keeping it into a single task. With some plumbing, I guess you can fire multiple thin instances and then allow you to start your cluster of thin (or whatever you use) instances and have still one task to rely on.
I'd say that adding a handler to the SIGINT signal could allow you to run some code before exiting. See http://www.ruby-doc.org/core-1.9.3/Signal.html for how to do that. You might want to check if Thin isn't already registering a trap for that signal, I'm not sure if this is handled in the library or in the script used to launch thin ( the "thin" executable that gets in your $PATH).
Another way to handle the exit, would be to have a watchdog process, that check if your cluster is running and could ensure the stop code is being ran if no more instances are running.
i am new to heroku and node.js. i have a small node.js app which i can start and run successfully on my local machine using FOREMAN from the heroku toolbelt. i do not understand how to best debug the app, though.
i see that there is an eclipse debugger for node.js as well as the node-inspector project. but i cant seem to make these work with FOREMAN.
foreman start
if it is not possible to debug an app started by foreman, what is the purpose of foreman?
Just an addition, your Procfile could look like this:
web: node web.js
webDebug: node --debug-brk=5858 web.js`
So to start debugging you just call foreman start webDebug, you could call the configuration however you want.
The debugger will listen on port 5858 and you'll have to call your app from http://localhost:5100 instead of http://localhost:5000.
The purpose of Foreman is to allow you to run complex applications, which may consist of several processes, easily. Check out the author's blog post on Foreman:
Lately I've noticed my web apps are getting complicated to run. My
apps no longer consist of a single web process; I usually have have
one or more types of background workers to run different types of jobs
and a clock process to handle scheduling. Splitting an app up in this
way is great for performance and scalability. The downside, however,
is that it becomes much more complicated to get the app and all of its
parts running.
Foreman is an attempt to make this easier. Using foreman you can
declare the various processes that are needed to run your application
using a Procfile.
By leveraging Foreman, Heroku has made it so that you can essentially run any kind of process you want to--a Rails app, a Sinatra app, a Node.js app, or anything else--simply by specifying how to start it in your Procfile, which Foreman reads and executes.
Foreman also allows you to take this simple Procfile and export it to production environments using tools like Upstart and Init. It does not provide any debugging functionality (nor is it meant to).
I have just written my first EventMachine application. In development, to start the server, all I do is:
ruby myapp.rb
Which runs my application until I kill it with control+C. In production, this doesn't seem like the right way to do it.
How would I go about running this on my production server?
Check out daemons: http://daemons.rubyforge.org/ - a simple gem written for precisely this use case.
At PostRank we always used God to start/restart our production EventMachine APIs.
I prefer to have a completely external process handling my daemons rather than using something like the daemons library but that's a personnal preference.
You have many solutions out there, here those I know of, all of them will restart your application when it crash more or les quickly and some offer a management interface whether it is a cli or a web interface:
supervisord (http://supervisord.org/): he one I prefer so far
daemontools (http://cr.yp.to/daemontools.html): works well but can be anoying to configure
god as mentionned (http://god.rubyforge.org/): Never used it most for this horrible and cryptic config file syntax
And the last one is whatever comes with your linux distrib, init can run an application and restart it when it dies, you have neary no control over it but it can do the job.
You can type "man inittab" to learn more.
I want to start my Rails server in a background thread from within a Ruby script. I could use Kernel#system but I want to be able to kill the Rails server when the thread is stopped. Is there a way to execute the Rails server using some Rails API call instead? I'm thinking something it would be nice to be able to put something like Rails.run_server(:port => 3000, ...)
I'm on Windows Server 2008.
Check out the file gems/rails.x.x.x/lib/commands/server.rb. It looks like that's the starting point that script/server uses.
Since script/server is itself a ruby script, it stands to reason that you ought to be able to start a server by doing something similar to what's in server.rb. But I imagine you might have some difficulty getting your ruby environment right...
Note that I'm looking at rails 2.3.8 here, so if you're on 3.whatever your results will probably be different.
I eventually decided to avoid any ickiness and start the rails server in its own process, as detailed in this post. (Being able to kill it plus its child processes consistently was the main blocker and the original reason I'd considered starting it in a thread instead.)