We have a situation in our project in which we need to access same methods in different Api test cases. Currently we have copy pasted all these methods in every Api test cases. Is it possible to make these methods in a common method and access from it?
It is possible to store these methods in Global variable. It will work fine in Postman, but it fails while running in Newman.
There are two ways you can go about this - both of them are "hacky" and by that I mean that they are a byproduct of what Postman allows you to do for other purposes.
Create a function and assign it to a variable of the window object - there's an example in one of the the GitHub threads on the Postman project. Quote:
I've found a hackish workaround is to wrap functions you want to share
across test inside a global object. In your first pre request script
it would look something like this:
// window.{name of wrapper}
window.Utils = {
percentChange: function(val1, val2) {
return (((val1 - val2) / val2) * 100).toFixed(2) + '%';
}
};
In all the tests that are run after you can call that function without
needing to put 'window' before it
Utils.percentChange(responseTime, newTime);
I actually couldn't manage to get this to work, plus it was not viable for my case, because I wanted to create a framework that would be defined only once and then available in any request.
A blogger - sorry I cannot find the original blog post right now - suggested an approach which I ultimately used successfully.
EDIT: The almost exact solution is showcased on a blogpost (TIP #5: reuse
code) on the official Postman blog.
2.1 Create your reusable code and then store it as an environment or global variable.
2.2 In your pre-request or tests script, call eval on the variable that you defined in the previous step.
NB: There is one major issue with either approach - debugging problems or changing the reusable code that you have stored. I struggled with this when I needed to determine where an inconsistent behavior of the reusable code was coming from. Basically, I ended up using console.log a lot.
Related
Creating in-repo-addon in Ember.JS gives a lot of possibilities. Today I've stumbled into a case when I wanted to register all classes in directory (for example my-dir) into Dependency Injector (same way it's done with services by Ember, but I wanted to use some other namespace).
For example I want to allow developer to create multiple classes inside proxy directory, and register all of them in DI under proxy: namespace. So later we can use:
Ember.Component.extend({
myProxy: Ember.inject('proxy:my'),
});
You'll need to do this using an initializer. More details on this here: https://guides.emberjs.com/v2.12.0/applications/dependency-injection/
The hard part may be getting all proxy items in s folder to automatically register ...
Edit
Looks like I didn't spend enough time thinking about this. You should be able to do at least part of this easily. There are two parts to this.
Part 1
Ember currently uses the ember-resolver to handle lookups for various items. If you check the tests for the resolver you'll notice that you should be able to map in anything you want: https://github.com/ember-cli/ember-resolver/blob/master/tests/unit/resolvers/classic/basic-test.js
So in your case, if you do a Ember.getOwner(this).lookup('proxy:main') from within an Ember instantiated class (a route, controller or component for instance) it would look in app/proxy/main.js which your addon could be populating.
Details on the Ember.getOwner lookup are available here: https://emberjs.com/api/classes/Ember.html#method_getOwner
Part 2
So at this point you can lookup proxies (which would be doable in an init method). But if we want to get truly elegant we'd want to allow Ember.inject.proxy('main') syntax.
Doing so would involve calling a private method inside of Ember.inject in an initializer. Because that naming scheme is changing in the new Javascript modules RFC, it may be unwise to try to add this syntactic sugar ...
So I'd advise avoiding touching that private API unless it's really important to your app design.
Previously when I developed ember application I used App as my global object and every class was stored in this big object.
Like this
window.App.MyModel = Em.Object.extend({});
And in the browser console, I was able to do
App.MyModel.create();
So it was really easy for me to access MyModel class.
Now I started experiments with Ember-CLI, I don't have much experience with this kind of tools. I followed the documentations and I created my model Service like this.
var Service = Ember.Object.extend({});
export default Service
But now, how to access Service class from browser console?
Only way I found was:
App.__container__.resolve('model:service')
But I don't like it much. Is there better way? Btw, can you please explain how export works? Or is there some source (documentation, article) where I can study it?
Thanks a lot for response.
If you're aiming to have something available in most places throughout your application you'll typically want to register it on the container.
There are multiple ways to access the container, and you're correct in that the one you found was less than ideal. The running joke is "any time you directly access __container__ we need to add more underscores."
To directly control how things are registered on the container and injected into the container you typically want to use an initializer. Using initializers in ember-cli is super-easy, they're executed for you automatically.
Checking out the documentation you can see that you get access to the application's container as an argument which allows you to manipulate it in a safe manner.
Once you have access to the container you can use register and inject to make content easily available in particular locations. This was introduced here. One note, accessing things inside of the container from outside the context of your app (browser console) will require the usage of App.__container__ and that is the expected use pattern.
And the export you're running into is an ES6 module system construct, it's not Ember-specific. Playing with the ES6 module transpiler can give you a good sense of what goes in and what comes out in "we can do this today" type of JavaScript.
For ember 3.22, application classes can be accessed like so:
Ember.Namespace.NAMESPACES[1]._applicationInstances.values().next().value.lookup('service:state-events')
Note, you may need to modify the index in NAMESPACES[1] to be something other than 1. You can determine which namespace is your application when this returns true:
Ember.Namespace.NAMESPACES[1] instanceof Application
This approach is how ember-inspector accesses ember applications: https://github.com/emberjs/ember-inspector/blob/50db91b7bd26b12098cae774a307208fe0a47d75/ember_debug/main.js#L163-L168
how can I use the controllers created at
/administrator/components/com_mycom/controllers/*
in
/components/com_mycom/mycom.php
In detail:
I have a »log« controller with an »add« method, and I would like to use this from the frontend. I one is not logged in in the backend the task is not executed and a 500 error rises. So just would like to include the backend controllerpath in the frontend, so that JController::getInstance( 'Mycom' ) still works.
Greetings…
EDIT:
After a long time of searching I could find a more or less undocumented Parameter of the:
JController::getInstance() method, namely the second one: $config = array(). Going through the source code I found out that there is one key of the »config-array« that is of interest, which is: »base_path«.
The call of:
JController:getInstance( 'Mycom, array('base_path' =>JPATH_ADMINISTRATOR.DS.'components'.DS.'com_mycom')' );
always delivers the backend controller and one can use them safely in the frontend, BUT one must take care that then also the views are taken from the backend side of the component. In my case, I just use it to make ajax-calls so it does not matter, but one needs to be careful with using this method when planning to create »frontend views« with »backend controller«.
Greetings…
I had recently a similar problem where I wanted to use the whole CRUD system form back-end also in front-end.
This is the method that worked for me (and I am not saying that this is recommended or best practice):
I've just modeled the folders / file structure from backend. PHP files contained something like:
require_once JPATH_ADMINISTRATOR . '/components/com_mycom/controllers/log.php';
When using sinatra-r18n to handle internationalisation, the r18n lib exposes a variable t for use within your helpers, routes and templates, as per these instructions.
I have written a simple unit test using rack-unit to confirm that some of my pluralisations work but the test throws an error claiming t is nil.
I've tried referencing it via app.t, MySillyApp.t (where MySillyApp is the name of my Sinatra app), MySillyApp.settings.t etc and none of them give me access to the t I need.
What I am trying to achieve is a confirmation that my translation files include all the keys I need corresponding to plurals of various metric units my app needs to understand. Perhaps there is a more direct way of testing this without going via the Sinatra app itself. I'd welcome any insight here.
I had similar task to check localized strings in my Cucumber scenarios.
I've made working example.
Here you can find how strings got translated.
This file halps to understand how to add R18n support to your testing framework:
require 'r18n-core'
...
class SinCucR18nWorld
...
include R18n::Helpers
end
As you can see instead of rack/unit I'm using RSpec/Cucumber, sorry.
I'm creating a DB web application with grails for my company and found myself in the need to change the default scaffolding templates.
So far so good, everything gets generated with the modified templates (controllers, views, ..).
Now, however, I get a request to create some "composite screens" with functionalities and a layout that differ from the overwritten templates.
So now my question is: is it possible in grails to create one or more templates (next the the default one) and pass this template name as an argument to the generate-* commands?
Thanks in advance!
EDIT: Adding the template name to the generate commands was just an idea, if it's possible to do this a different way, I'll be happy too.
Grails commands are scripts in grails/scripts. If you follow its logic you will see two things.
1) There is only one parameter passed to the script → domain.
2) Class for generating views is DefaultGrailsTemplateGenerator. You can analyse sourcecode and check what this class offers.
Update
Link to DefaultGrailsTemplateGenerator in GitHub.
I am not sure about the generate command parameters, but if you add another .gsp page into scaffolding directory, I believe it will try to run it through generation process.
So for example I used to have a show.gsp page as well as showBasic.gsp page, which showed fewer properties.