My VCR configure block is:
VCR.configure do |c|
c.cassette_library_dir = 'spec/fixtures/vcr_cassettes'
c.hook_into :webmock
c.around_http_request(lambda { |req| req.uri =~ /google.com/ }) do |request|
VCR.use_cassette(request.uri, :decode_compressed_response => true, &request)
end
end
My tests work fine for post/get/put methods but when I try to DELETE, there is a clash in VCR because it matches with a previous PUT request. This is because the URI for that request is the same as the one needed for the DELETE request.
How do I change my use_cassette method so that it uses a combination of URI + method? (or any other suggestion also welcome!)
Thanks!
Solved it, this might help others, so leaving it here:
VCR.use_cassette([request.uri,request.method].join.to_s, :match_requests_on => [:method, :uri], :decode_compressed_response => true, &request)
Related
How could I get the name / version of the next migration to execute? Something similar to migrations:latest but more like migrations:next. I need this as input to another command so it needs to be parseable output (can't really just use migrations:status).
You can use the Configuration object of the Doctrine migrations bundle. This is even (somewhat) documented as custom configuration.
Here is a minimal code example that works for me:
public function migrationVersionAction(EntityManagerInterface $em, ParameterBagInterface $parameters) {
$connection = $em->getConnection();
$configuration = new \Doctrine\Migrations\Configuration\Configuration($connection);
$configuration->setMigrationsNamespace($parameters->get('doctrine_migrations.namespace'));
$configuration->setMigrationsDirectory($parameters->get('doctrine_migrations.dir_name'));
$configuration->setMigrationsTableName($parameters->get('doctrine_migrations.table_name'));
return new JsonResponse([
'prev' => $configuration->resolveVersionAlias('prev'),
'current' => $configuration->resolveVersionAlias('current'),
'next' => $configuration->resolveVersionAlias('next'),
'latest' => $configuration->resolveVersionAlias('latest')
]);
}
You might want to set the remaining parameters as well though, especially if they differ from the defaults. For this, the configuration documentation might help in addition to the link above.
app.get('/:service[SOMETHING GOES HERE]', function(req, res, next){
console.log('Service is:', req.params.service);
});
This needs to catch URLs that can look like any one of:
/foo
/foo/bar
/foo/bar/baz
The call back isn't concerned with anything that comes after foo, but ideally should be able to access foo as a parameter called service without having to manually parse the path.
I've been using this to test and still haven't found anything that does exactly that. Closest so far is /:service*.
Edit: No it's not a duplicate of the one where the answer is /:service/* because that doesn't cover /foo.
Using /:service* in actual Express routes does exactly what you want:
/foo maps to { '0': '', service: 'foo' }
/foo/bar maps to { '0': '/bar', service: 'foo' }
/foo/bar/blah maps to { '0': '/bar/blah', service: 'foo' }
The Express Route Tester, for some reason, maps these URL's differently for that these kinds of patterns (it might be configured differently than Express).
You can use the app.use() function for that. Read the doc about path handling for more info. Your code once modified will be:
app.use('/foo', function(req, res, next){
console.log('Service is:', req.params.service);
});
The downside is that you are not going to recover foo as the service parameter.
I have a simple test to fetch one Facebook object. I'm using Curl for the request.
it "gets an object from Facebook" do
VCR.use_cassette('facebook') do
url = "https://graph.facebook.com/<ID>?access_token=#{#access_token}&#{query_string}"
curl = Curl::Easy.perform(url)
expect(curl.body_str).to eql('<my object>')
end
end
My VCR configs are:
VCR.configure do |c|
c.cassette_library_dir = 'spec/fixtures/vcr_cassettes'
c.hook_into :webmock
end
When I run the tests, it passes, and the following is logged:
[Cassette: 'facebook'] Initialized with options: {:record=>:once, :match_requests_on=>[:method, :uri], :allow_unused_http_interactions=>true, :serialize_with=>:yaml, :persist_with=>:file_system}
[webmock] Handling request: [get https://graph.facebook.com/<ID>?access_token=<TOKEN>&fields=%5B%22id%22,%22account_id%22,%22name%22,%22campaign_group_status%22,%22objective%22%5D] (disabled: false)
[Cassette: 'facebook'] Initialized HTTPInteractionList with request matchers [:method, :uri] and 0 interaction(s): { }
[webmock] Identified request type (recordable) for [get https://graph.facebook.com/<ID>?access_token=<TOKEN>&fields=%5B%22id%22,%22account_id%22,%22name%22,%22campaign_group_status%22,%22objective%22%5D]
But the cassette is not recorded and the dir is empty. I've tried :record => :all to same results.
Usually, people encountered this error when using incompatible hooks for the library they're using, but that's not the case. I'm using webmock and curb.
Curiously, the cassette is recorded when there's a failure in the request, e.g., the token is expired. When it's fixed, and I delete the file, it's not recorded again.
Have anyone had the same problem?
It turns out that my code was a little more complicated than above and was executing a callback after perfoming the request. Something like:
success_handler = Proc.new { return c.body_str }
curl.on_success do |easy|
success_handler.call(easy)
end
That bypasses VCR and the file is not written. Refactoring the code to not use callbacks works.
I've kinda been struggling with this for some time; let's see if somebody can help me out.
Although it's not explicitly said in the Readme, ember-data provides somewhat validations support. You can see that on some parts of the code and documentation:
https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/states.js#L411
https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/states.js#L529
The REST adapter doesn't add validations support on itself, but I found out that if I add something like this in the ajax calls, I can put the model on a "invalid" state with the errors object that came from the server side:
error: function(xhr){
var data = Ember.$.parseJSON(xhr.responseText);
store.recordWasInvalid(record, data.errors);
}
So I can easily to the following:
var transaction = App.store.transaction();
var record = transaction.createRecord(App.Post);
record.set('someProperty', 'invalid value');
transaction.commit()
// This makes the validation fail
record.set('someProperty', 'a valid value');
transaction.commit();
// This doesn't trigger the commit again.
The thing is: As you see, transactions don't try to recommit. This is explained here and here.
So the thing is: If I can't reuse a commit, how should I handle this? I kinda suspect that has something to do to the fact I'm asyncronously putting the model to the invalid state - by reading the documentation, it seems like is something meant for client-side validations. In this case, how should I use them?
I have a pending pull request that should fix this
https://github.com/emberjs/data/pull/539
I tried Javier's answer, but I get "Invalid Path" when doing any record.set(...) with the record in invalid state. What I found worked was:
// with the record in invalid state
record.send('becameValid');
record.set('someProperty', 'a valid value');
App.store.commit();
Alternatively, it seems that if I call record.get(...) first then subsequent record.set(...) calls work. This is probably a bug. But the above work-around will work in general for being able to re-commit the same record even without changing any properties. (Of course, if the properties are still invalid it will just fail again.)
this may seem to be an overly simple answer, but why not create a new transaction and add the pre-existing record to it? i'm also trying to figure out an error handling approach.
also you should probably consider writing this at the store level rather than the adapter level for the sake of re-use.
For some unknown reason, the record becomes part of the store default transaction. This code works for me:
var transaction = App.store.transaction();
var record = transaction.createRecord(App.Post);
record.set('someProperty', 'invalid value');
transaction.commit()
record.set('someProperty', 'a valid value');
App.store.commit(); // The record is created in backend
The problem is that after the first failure, you must always use the App.store.commit() with the problems it has.
Give a look at this gist. Its the pattern that i use in my projects.
https://gist.github.com/danielgatis/5550982
#josepjaume
Take a look at https://github.com/esbanarango/ember-model-validator.
Example:
import Model, { attr } from '#ember-data/model';
import { modelValidator } from 'ember-model-validator';
#modelValidator
export default class MyModel extends Model {
#attr('string') fullName;
#attr('string') fruit;
#attr('string') favoriteColor;
validations = {
fullName: {
presence: true
},
fruit: {
presence: true
},
favoriteColor: {
color: true
}
};
}
I'm working on my first ZF project and am a bit stuck. I have a controller named 'WebServiceController' and I have a unit test for the WebServiceController but when I run the test it doesn't assert the controller properly. My test code is:
public function testIndexAction() {
$params = array('action' => 'index', 'controller' => 'WebService', 'module' => 'default');
$url = $this->url($this->urlizeOptions($params));
$this->dispatch($url);
// assertions
$this->assertModule($params['module']);
$this->assertController($params['controller']);
$this->assertAction($params['action']);
$this->assertQueryContentContains(
'div#view-content p',
'View script for controller <b>' . $params['controller'] . '</b> and script/action name <b>' . $params['action'] . '</b>'
);
}
The error I get is:
1) WebServiceControllerTest::testIndexAction
Failed asserting last controller used <"Web-Service"> was "WebService"
It looks like its trying to assert the controller was 'Web-Service' instead of 'WebService'. Can anyone point me in the right direction?
Thanks in advance.
Ziad
p.s. I am using ZF 1.11.5
In Zend Framework a camel case name for controller is rewritten in the URL :
WebService in the class name becomes web-service in the URL.
This is a normal behavior, see http://framework.zend.com/manual/1.12/en/zend.controller.basics.html :
Since humans are notoriously
inconsistent at maintaining case
sensitivity when typing links, Zend
Framework actually normalizes path
information to lowercase. This, of
course, will affect how you name your
controller and actions... or refer to
them in links. If you wish to have
your controller class or action method
name have multiple MixedCasedWords or
camelCasedWords, you will need to
separate those words on the url with
either a '-' or '.' (though you can
configure the character used). As an
example, if you were going to the
action in
FooBarController::bazBatAction(),
you'd refer to it on the url as
/foo-bar/baz-bat or /foo.bar/baz.bat.