I have two ducttape files: globals.tape and myfile.tape and I am importing globals.tape in myfile.tape as shown below:
globals.tape
global {
ducttape_experimental_imports=enable
ducttape_experimental_packages=true
num_days=(NumDays: 1="1" 2="2")
}
myfile.tape
import "../tapes/globals.tape"
plan planA {
reach do_some_task via (NumDays: 5)
}
Since NumDays can only take values 1 and 2, I want to add a validation step which will make sure that NumDays always take one of the available/valid values.
How do I do the validation? For example, is there any parsing tool that loads all imported tape files and checks if the variables resolve correctly? Alternatively, is there any ducttape API that can be used to do the validation?
I recommend just adding a task that does the validation directly in bash. You can make the task that consumes those params depend on that task.
Related
I'm writing API tests using Postman. I'm organizing them into folders by endpoint, and subfolders by test cases within the endpoint folders. There are multiple cases for each endpoint and for each case there are post calls that set up data prior the the csubject-endpoint call that I'm making assertions against.
I already have 100s of calls in this suite. The test runner, unfortunately, does not provide the folder names in its output, so it's difficult to see at a glance which particular case I am looking at when, for example, it reports a test fail.
Is there a convenient way to obtain the folder names for a given call in its test script? With this, I could prepend the case name to the test name, and that would make my tests vastly more readable.
I think a variable containing the current request path in the folder hierarchy would be the best, but for now I didn't find such a feature.
Instead I may suggest such a workaround solution:
In each folder prerequest scripts you set a variable:
pm.environment.set("folder", "folder1/folder1.1/")
the value of folder variable you have to maintain separately for each folder.
Then on a collection level you put a collection test like this:
pm.test("location: " + pm.environment.get("folder"), true)
After running your collection in the Runner you will get the output
from collection tests at the beginning of the test results for each request
showing the folder location.
The effort of setting folder variables pays off when you estimate the results of complex tests. I used to change the names of the requests but it is even more complicated.
UPDATE:
You can also find the info in results hovering over a gray shortcut of path on the left of the request status. A tooltip displays a full path, what in fact eliminates the need of the above solution if you only want to observe the results, but the solution can be useful if you want to make some logs containing the path.
I don't think that there is anything like that from within the application - The closet I can see is the pm.info.requestName function which references the request name that the test belongs too.
This is a basic use case but you could add this to the test name to give you a 'quick glance' and what was run against what request.
pm.test(`${pm.info.requestName} - Status code is 200`, () => {
pm.response.to.have.status(200)
})
If you take a look at Newman it might have something within the summary object that you could extract, in a script, to get the folder name but I've never done this.
Closest thing right now would be this:
I believe I included this in my logged bugs / feature requests out to their team.
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.
In a nutshell, I keep finding forums on how to use the route prefixes, but I am wondering where it is in the source code that Laravel converts route prefixes into parameters that can be used in the views example: {customer_id}
It looks like on 794 of Illuminate/Routing/Route.php getPrefix() is used to get the prefix of the route instance; however, I'm not seeing where that is actually called.
I am trying to test a controller in Laravel 5.2 with PHPUnit/Mockery, Doctrine 2, and about 15 other dependencies. I have route prefixes of admin and customer that need to be pulled down as parameters. Everything on the live site works fine, so I know the actual code is correct. The other parameters work fine -- just not static prefixes. The tests worked great with Eloquent and had no problems converting the prefixes to parameters before my manager added a bunch of new dependencies. Now the prefix parameter returns null during testing on every test. One of the new dependencies broke something involved with testing--likely autoloading.
I could be looking in the wrong direction seeing how we are using so many dependencies that makes it extremely difficult to track down problems, but I've already found that Illuminate\Support\Facades\Route;
was autoloaded prior to the merge, and now it needs to be manually added to the testcase. I'm wondering if this isn't the same thing I need to do to get the route prefixes to work properly.
It looks like I was looking in the wrong place and converting the first static prefix to a variable was a new custom feature that parsed the route in helpers.php added by a coworker. That method was then called from middleware--which I had middleware turned off for testing, so the test never retrieved that first parameter.
I would like to ask about this controller.
In past versions like 1.5 I could find it in admin/tabs and add additional functions.
In 1.6 version I can`t find any admin classes files. So I should edit controllers/admin/AdminOrdersController yes?
elseif(isset($_POST['submitInvoice'])){
if ($this->tabAccess['edit'] === '1')
{
mysql_query('UPDATE `'._DB_REFIX_.'orders` SET `invoice_number` = \''.$_POST['invoice_number'].'\',`order_date` = \''.$_POST['order_date'].'\', `changed_invoice`=1, `manager`=\''.$cookie->firstname.' '.$cookie->lastname.'\', `changedStatus`= \''.$_POST['changedStatus'].'\' WHERE `id_order` = '.$_GET['id_order']);
}
}
I add this code to update some values like invoice number or order date. But I can`t to update this. Got same date and number. Is it bad method to update or what?
You should always use modules and hooks to modify PrestaShop logic if possible
If you need to override a function and there is nor suitable hook, you should use overrides: override/controllers/admin/AdminOrderController.php. Contents of this files should look like : AdminOrderController extends AdminOrderControllerCore. If you're unsure what I mean, you should try searching for any override classes in overide folder.
You code is extremely unsafe. You should at least use Db::getInstance()->execute($sql);.
You code might not be working because you are writing you values somewhere in the middle of a function, and the Order is an object, which mean that possibly the Order object is saved after you wrote you values to database. When the order object is saved, it overwrites your values
I have a SOAP UI 4.5.1, I have made a load test, it is working fine. My problem is that I run the same request every time and I need to change the values of the soap request I am sending.
For e.g. I have a block of my soap request:
<ns:Assessment>
<ns:Project>
<ns:ProviderId>SHL</ns:ProviderId>
<ns:ProjectId>SampleAssessment</ns:ProjectId>
</ns:Project>
</ns:Assessment>
Provider ID: SHL
Project ID: SampleAssessment
Is there a way to make those values changing from some kind of interval?
For e.g.: Provider IDs [SHL, SLH, LHS]
Project IDs [SampleAssessment, TestAssessment, AnotherAssessment]
And with a load test I am making three request so that for the first request values looks like this:
<ns:Assessment>
<ns:Project>
<ns:ProviderId>SHL</ns:ProviderId>
<ns:ProjectId>SampleAssessment</ns:ProjectId>
</ns:Project>
</ns:Assessment>
for the second like this:
<ns:Assessment>
<ns:Project>
<ns:ProviderId>SLH</ns:ProviderId>
<ns:ProjectId>TestAssessment</ns:ProjectId>
</ns:Project>
</ns:Assessment>
and so on...
Is there a way to make this happen with SOAP UI?
From my experience, you will need to use a Groovy Script step.
For example, if you have a step before your request that is a script, you can use something like:
context.setProperty("ProviderId", "SHL")
Then in your request, use:
<ns:ProviderId>${ProviderId}</ns:ProviderId>
Of course, this doesn't buy you much by itself. There are few ways to vary what the context.setProperty("ProviderId", "SHL") line will set. You can create a collection and iterate over it using something like:
def providers = ['ABC', 'DEF', 'GHI', 'JKL']
providers.each() {
context.setProperty("ProviderId", it)
testRunner.runTestStepByName( "nameofteststep" )
}
Where "nameofteststep" is the name of the Soap Request test step. This might sound odd, but if you right click the test step and disable it, the groovy script will still be able to execute it but it will not run sequentially. By that I mean that the groovy script will run it 4 times, but it won't run a fifth time when the script is complete because it is after the script. Then you just need to keep in mind that each load test thread makes four requests, but I am pretty sure that the SoapUI statistics will take this into account for you... might want to keep an eye out for it, though.
Alternatively, you could check the 'threadIndex' and set a the context variable based on that. A bit like this here: Log ThreadCount.
You could also use a collection without a loop and increment an index that you save as a testcase property and send the string corresponding to the index.
Personally, I think the first way is the most straightforward but I can provide an example of the other ones if you like.
There is a simple way of doing this without writing a groovy script.
After creating a test case you should include the below test steps:
1-Data source
2-Request
3-Loop
Data source will read an excel file (or other data source methods such as XML, groovy, JDBC, gird .. however the excel is the simplest one).
You should include the datas (that you need to change within the request)
Within the test request you need the right click and select "get data" . please notice that your test request should be as below
<ns:ProviderId>${ProviderId}</ns:ProviderId>
Then the last step is the "Loop" . This for returning to the first step until the data ends.
I hope this helps.