I've noticed that some V8 API methods do not require that a context be entered, while others do. For example, String::New works without a context, but String::Utf8Value won't workâinstead, the process crashes.
Is there a general rule as to what portions of the API require a context be entered, and which ones don't? The documentation doesn't seem to specify when a context is required.
Related
The very first line written about sinatra is it is DSL for quickly creating web applications in Ruby with minimal effort. I can understand it is light weight, very flexible, quick for creating web apps and with minimal effort but not able to understand how it is a DSL?
One reason is that it defines actions ("verbs") within its domain as methods, for example:
get '/hi' do
"Hello World!"
end
Here Sinatra has incorporated an action from its domain--namely the HTTP request method "GET"--into its "vocabulary."
(Similar to building a library around banking and defining methods like account or customer.)
Is this more about the true definition of DSL?
I just completed writing a detailed rspec capybara integration and unit tests for Rails app, which includes mocking Omniauth (twitter) login, filling in forms, data validations, etc. However, I am wondering whether there is a need to write a separate controller or functional test.
Would appreciate your input and any links to further readings etc.
I'll play devil's advocate here, since I know I'm probably in the minority with this opinion: I actually prefer to do exceedingly thorough controller testing. A few reasons:
1) I find it easier to systematically test every path and outcome at the controller level than at the integration test level. My integration tests are primarily just happy-paths, and some of the more common error paths.
2) A lot of potential security issues occur at the controller level. Thorough testing helps me ensure that nothing malicious can get through to my model logic.
3) This is subjective, but it really forces me to think about some of the long-tail paths that my application might go through. What if someone tries to for an invalid password reset token into the URL? Controller testing ensures that I consider all options.
4) Unlike integration tests, they're fairly straight-forward to test. Each action is just a ruby method!
Personally, I think if your request (integration) spec is exercising all code paths you're covered. Ryan Bates has a great Railscast about how he tests here: http://railscasts.com/episodes/275-how-i-test?autoplay=true and about 5:05 in he says a similar thing. Like you I like to write integration tests rather than controller specs. Most of the time controllers simply front CRUD type operations anyway (especially if you're careful about keeping domain logic out of the controller), so all you're testing is the scaffolding.
We have a isolated test automation team responsible for automating only watir+cucumber functional test cases. Their code base is not attached with the rails app that other developers are working on, but kept separate. We have automated several test cases so far, and now what problem we have is, some (watir/cucumber specs)test cases require some data to be preexist into db, so it(testcase) should focus only on the problem stmt, and not creating any data-require itself.
Example, say if it has to check whether rating is working for a post, it requires a post object should preexist and it just checks rating. And not creating 1st post object and then checking its rating.
What are the best approaches here? Like we have fixtures and factory-girl for rails unit testing, what is there for cucumber specs? Or Shall we make use of features only here? These testers may not have idea of all models that exist, do they be aware of them so to make use of fixtures by calling Rails-Model interface.
My idea was, when we write feature file, it should not point or talk about any Model which looks meta stuff. Watir/specs test cases should only be aware of "Web-application"/browser only as the interface to talk/deal with the application. They should not know any other interface(fixture/Models). Hence they should create their own data on their own, by making use of the single interface they know.
Again, what I want to know that, is there any ruby lib/code, given table names, column names, and values(all most like fixtures yml), along with db parameters. It will simply insert them into db, without context of rails environment. And so testers those are having their environment isolated from rails web developers would able to work on their own. Rails fixtures, or factory girls seem to be well coupled with rails. Or am I incorrect?
Like Chirantan said you could use Factory girl with cucumber.
As require your factories in test unit or RSpec, you can do the same in the cucumber's env.rb file or any custom config file.
http://robots.thoughtbot.com/post/284805810/gimme-three-steps
http://www.claytonlz.com/2010/03/zero-to-tested-with-cucumber-and-factory-girl/
http://www.andhapp.com/blog/2009/11/07/using-factory_girl-with-cucumber/
When using cucumber, the Given statement sets the test situation up:
Given I have a basic user with a password
and the When statement triggers the test:
When the user logs in
and the Then statement checks the test results
Then they see the basic menu
The data gets loaded in the Given statement.
I created an ASP.NET MVC4 Web API service (REST) with a single GET action. The action currently needs 11 input values, so rather than passing all of those values in the URL, I opted to encapsulate those values into a single class type and have it passed as Content-Body. When I test in Fiddler, I specify the verb as GET, and enter the JSON text in the "Request Body" input box. This works great!
The problem is when I attempt to perform Load Testing in Visual Studio 2010 Ultimate. I am able to specify the GET action and the JSON Content-Body just fine. But when I run the Load test, VS reports exceptions of type ProtocolViolationException (Cannot send a content-body with this verb-type) in the test results. The test executes in 1ms so I suspect the exceptions are causing the test to immediately abort. What can I do to avoid those exceptions? I'd prefer to not change my API to use URL arguments just to work-around the test tooling. If I should change the API for other reasons, let me know. Thanks!
I found it easier to put this answer rather than carry on the discussions.
Sending content with GET is not defined in RFC 2616 yet it has not been prohibited. So as far as the spec is concerned we are in a territory that we have to make our judgement.
GET is canonically used to get a resource. So you are retrieving this resource using this verb with the parameters you are sending. Since GET is both safe and idempotent, it is ideal for caching. Caching usually takes place based on the resource URI - and sometimes based on various headers. The point is cache implementations - AFAIK - would not use the GET content (and to be honest I have not seen any GET with content in real world). And it would not make sense to include the content in the key generation since it reduces the scalability of the caches.
If you have parameters to send, they must be in the URI since this is part of what defines that URI. As such, I strongly believe sending content with GET is wrong.
Even when you look at implementations such as OData, they put the criteria in the URI. I cannot imagine your (or any) applications requirements is beyond OData query requirements.
I was hoping to make a Rails app usable both as an Engine and as a standalone Application.
Specifically, I have a nascent app which I'd like to plug in to a customer's site, but ideally, I'd like to just as easily use the app as a standalone system. However, if config/environments/*.rb exist in the enginified version of my app, I get an Uninitialized Constant error at the time the app that I'm having take a dependency on my engine starts up; Rails complains that the MyEngineModule::Application constant can't be found in development.rb, which I think is simply a load order issue, since this does NOT occur when I run the app standalone. If I delete development.rb, the original initializers that reference my MyEngineModule::Application complain, so then I tried to delete those, and all is well.
Great, except that the original app doesn't work, since its configuration is gone.
Is there some tweak I can make to the initialization load order (or load paths, in the Engine < Rails::Engine class definition) that would prevent the original configs and initializers from being loaded when in an engine context, and allow me to leave them in place for the app context?
The simpler answer is probably this, but I'm feeling stubborn, and would like to know what it would take to make my original goal possible:
extract the code for MyEngine into an engine, remove the config/environments/* files and config/initializers/* files, and make the client app depend on this.
Make a "new" minimalist app depend on MyEngine, and move the environment files and initializers to NewApp.
Assuming I feel some unnatural compulsion to keep my original application runnable as it was, if I want to prevent the "engine" from loading the "application" configuration, what's the best way to handle that? I presume this is only really a problem during development, because I can prevent the environments/*.rb files from being pulled into the gem itself, but I like being able to test locally while I'm developing the engine and its client app.
Continuing my tradition of answering my own esoteric questions, it seems like one passable alternative is to include a guard clause in the engine's environments/*.rb and the initializers that goes something like this:
if defined? CuteEngine::Application
CuteEngine::Application.configure do
config.whatever = something
end
end
This gets around the problem of having two Rails::Application objects at a relatively small cost. Not very happy about it, but I'll live.
Bumping this for new comers.
Rails 3.1 comes with mountable engines, which sounds like exactly what you are describing. The docs aren't great for converting existing code, but it looks like this will do what you want:
module CuteEngine
class Engine < ::Rails::Engine
isolate_namespace CuteEngine
end
end
In your other app's routes.rb file, you'll add:
mount CuteEngine::Engine, at: "/cuteness"
http://edgeguides.rubyonrails.org/engines.html#mounting-the-engine
http://railscasts.com/episodes/277-mountable-engines