So I was wondering - been using the aws-sdk-mock library for Node / Jasmine.
This particular library allows you to mock the service method invocations. However this appears to be a problem when attempting to mock a method called more than once, but fed different parameters (thus invoking a different lambda).
Aws.mock('lambda', 'invoke', function(params, callback){
callback(null, {})
}
This will mock every call to invoke, which really isn't flexible, what I think would be useful would be to see if the params passed to it contained a specific value.
Now I would not be tied to the AWS.mock framework I don't believe, so if anyone has any pointers how to handle this, it would be great. See the invocation flow below.
Custom function (called from test) -> custom function (calling the invoke)
I found the solution to this to be checking the parameters of the lambda being mocked. For example if you have a lambda named lambdaOne and a lambda named lambdaTwo, your mock would look like this:
Aws.mock('lambda', 'invoke', function(params, callback){
if (params.FunctioName === 'lambdaOne'){
callback(null, lambdaOneResponse)
}
else if (params.FunctioName === 'lambdaTwo')
callback(null, lambdaTwoResponse)
}
I hope this helps!
Related
I have multiple calls to ::Foo.bar. I would like to stub only the call that includes a very specific parameter.
Is it possible to do : ::Foo.stubs(:bar).with(1).returns(something) and still allow ::Foo.bar(2) to call the actual method?
You can use instance_of in the parameter, if the value will be an instance of the same class.
::Foo.stubs(:bar).with(instance_of(Integer)).returns(something)
Please refer the source code of with, a block can also be passed to match your requirements.
C++/WinRT's agile_ref supposedly allows usage of non-agile objects in an agile way.
However, I've found that this fails with at least CoreWindow instances.
As a short example:
void Run()
{
auto window{ CoreWindow::GetForCurrentThread() };
window.Activate();
auto agile_wnd{ make_agile(window) };
ThreadPool::RunAsync([=](const auto&) {
auto other_wnd{ agile_wnd.get() };
other_wnd.SetPointerCapture();
});
auto dispatcher{ window.Dispatcher() };
dispatcher.ProcessEvents(CoreProcessEventsOption::ProcessUntilQuit);
}
Run() is called on the UI thread, then attempts to create an agile reference and then use it to call the CoreWindow from the thread pool. However, this fails with "The application called an interface that was marshaled for a different thread." Since agile_ref uses RoGetAgileReference internally to marshal the object, and the calls to create the reference and then unmarshal it are both succeeding, this appears to me to be CoreWindow simply refusing to be marshaled at all.
Unless, of course, this is working as intended and the RoGetAgileReference call silently fails to marshal the CoreWindow.
So what causes the SetPointerCapture call to fail, even with the agile_ref?
The error is misleading. Most of the Windows.UI classes are actually agile. The challenge is that they perform an explicit thread check to ensure that you are actually calling them from the appropriate UI thread. That's why an agile_ref won't help. The solution is to use the Dispatcher, which gets you on the correct thread. You can then simply call methods on the object directly.
According to
http://graphql.org/graphql-js/authentication-and-express-middleware/
To use middleware with a GraphQL resolver, just use the middleware like you would with a normal Express app. The request object is then available as the second argument in any resolver.
However, when I run my resolver
module.exports = {
Query: {
books(root, args, context) {
return books;
}
}
};
the second argument is my query arguments. The third argument, however, unless I override the context config property to expressGraphql is indeed my request object.
My full config is
app.use(
"/graphql",
expressGraphql({
schema,
graphiql: true
})
);
Are the docs wrong, or am I doing something incorrectly?
Neither :)
Even when building your schema with plain ole' GraphQL.js (as opposed to using graphql-tools or another library), there's a couple of different ways to pass in your resolvers.
You can generate it by creating a GraphQLSchema object, for example, in which case your resolvers are included within the GraphQLObjectTypes you add to it. Here is a repo that does just that.
Alternatively, you can declare a schema using a string with buildSchema. You can see that being done in the docs. If you go this route, the only way to pass in your resolvers is to utilize the rootValue object passed into your endpoint configuration. Normally, the values parameters passed to your resolvers are
root
args
context
info
However, when you go the above route, you lose the first parameter... since I imagine we can't pass root to itself
It's a good illustration of why, if you're going to generate a schema declaratively, graphql-tools is the way to go.
How can I call a controller method manually specifying some input parameters yet still have method injection work for the parameters not specified (example below).
routes.php
$myController->index($id);
controllers/MyControllerOne.php
class MyControllerOne
{
public function index($id, MyRequest $request)
{
}
}
extra information
The reason I need this is because I have special information in my routes that determines which controller should be executed such as /myroute/{data}/{id}. It's a bit unorthodox but it's a necessary evil given the scope of our system.
Once I resolve within my routes which controller needs to be called I then want to call the method on that controller. $controllerInstance->index($id).
If it's only for Request, I think you could manually pass this $this->app->make('Request'), like so
$controllerIntance->index($id, $this->app->make('Request'))
Note that you actually don't have to inject Request, since you might as well use App::make inside of your controller. But I'm not sure how good this decision is in case of testability and coupling.
For more info:
This function resolves 'Request' out of the container, that is instantiates or returns an existing instance (depending of the type of service provider).
Using make is described here http://laravel.com/docs/5.0/container (see "Resolving"). I also found this answer helpful, to understanding how the container works https://stackoverflow.com/a/25798288/1627227
I have read a couple of posts on this topic, but neither addresses my issue directly. When you test a synchronous controller method, you can assert that the method is returning the type you expect:
Assert.IsInstanceOfType(result,typeof(JsonResult));
However, when testing async controller methods, I have only been able to assert that the type returned by the AsyncManager is the correct type:
var result = controller.AsyncManager.Parameters["articles"];
// Assertions
Assert.IsNotNull(result);
Assert.IsInstanceOfType(result,typeof(IEnumerable<NewsArticle>));
Seems to me I should be testing the return type of the Completed method which in my case is a JsonResult:
public JsonResult GetPublishedNewsArticlesCompleted(IEnumerable<NewsArticle> articles)
{
return Json(articles, JsonRequestBehavior.AllowGet);
}
But I haven't been able to figure out how to do this. I read a post by Dino Esposito in which he said that "the code of xxxCompleted is trivial and probably wouldn't even need a test". I am not buying it. The Completed method and it's return type is what I care most about in this test.
So my question is how do I test that my Completed method is actually giving me back a JsonResult? Or is Dino right and I just shouldn't care?
Thanks.
What I have done with my asynchronous methods is to just test the Async method and not the Completed method. My decision to do this is based on the fact that there is no business logic in the Completed method. All it does is serialize my return object and pass it back as Json or Jsonp if it is cross domain. I didn't write it and most folks will tell you if you don't write it, don't test it.