Handling test data for multiple scenarios and Environments in Playwright - playwright

does playwright have the support/ features to handle multiple test data for various scenarios and for multiple environments.
Could someone point me to the right approach for handling such scenarios.
scenarios:
Test will be executed in multiple environments ( Acceptance, prod etc).
test will have multiple scenarios which will require different set of test data.
I dont see a proper approach that i can used from the documentation ( or may be i am looking at the wrong place).
thanks in advance.
Allen K

At first you have playwright.config.ts file where you can set projects and their variables.
In ex
projects: [
{
name: 'chromium',
use: { ...devices['Desktop Chrome'] },
},
{
name: 'firefox',
use: { ...devices['Desktop Firefox'] },
},
{
name: 'webkit',
use: { ...devices['Desktop Safari'] },
},
or in your case it can projects with different environment.
Or you can create a Json structure of data that will need for particular test like.
{
"tcs":[]
{
"name": tc1,
"field1": value,
"field2": value,
},
{
"name": tc2,
"field1": value,
"field2": value,
}
}
Then just import this file in your suit and use all the data for particular test in foreach loop.

Related

Set camunda business key

I'm currently working on a project with camunda integrated. I was able to create a process instance, and everything else. But now I have to set the value of the businessKey. Does somebody know if there is any endpoint to do that? I'm working with grails5 and I have to do every call to the camunda by url
Full API documentation: https://docs.camunda.org/manual/7.17/reference/rest/
You would normally set the business key when the process instance is started:
https://docs.camunda.org/manual/7.17/reference/rest/process-definition/post-start-process-instance/
e.g.
{
"variables":{
"aVariable" : {
"value" : "aStringValue",
"type": "String"},
"anotherVariable" : {
"value" : true,
"type": "Boolean",
"valueInfo" : {
"transient" : true
}
}
},
"businessKey" : "myBusinessKey",
"withVariablesInReturn": true
}
You can also set the business key at other stages of the process, for instance in a scrip[t task or in expressions.

Can jenkins extended choice parameter be made dependent on another parameter's value?

I am using extended choice parameter with JSON parameter type in my declarative Jenkins pipeline. I have found it very good for providing custom UI for parameters and it returns a json based on user inputs.
I have a use case where what options are shown to user depends upon another parameter's value. I can achieve such functionality with active choice parameter but then I am stuck with radio buttons, checkbox, html input etc.
I found a suitable option here where I can make a property inside json dependent on another property:
{
"title": "An object",
"type": "object",
"properties": {
"fieldOne": {
"title": "I should be changed to 'foo'",
"type": "string",
"enum": ["foo","bar"],
"default": "bar"
},
"depender1": {
"title": "I depend on fieldOne to be 'foo'",
"type": "string",
"enum": ["lorem","ipsum"],
"options": {
"dependencies": {
"fieldOne": "foo"
}
}
},
"depender2": {
"title": "I depend on fieldOne to be 'bar'",
"type": "string",
"enum": ["dolor", "sit"],
"options": {
"dependencies": {
"fieldOne": "bar"
}
}
}
}
}
This works great when I try it here
But when I try the same on jenkins, it doesn't work. It shows all 3 textboxes. I saw the option of watching other params too but I couldn't find how to use it as an if else for my parameter.
This is a simple example, what I want to achieve requires UI of a dropdown-1 + Array(dropdown-2 + text field+text-field) where in array's text-field depend on value of dropdown-1, I cannot create the same UI in active choice.
Does any one know how options.dependencies could work in jenkins or same could be achieved using watch/other plugins?
if i got your question right, so you want to make it more smart way to select parameters.
So you can do it via groovy script.
Here is my example you can see on pic:
freestyle job config
Sorry, but i don't know how to better show freestyle job config.
So, logic is quite simple:
i'm collecting JSON on first parameter, and doing some parsing for it.
and then im using Environmets variable to show it's contents, depending on result from first part.
ps. i'm struggling right now with variable Hosts, as i don't know how to pass it in final steps without asking user for input.
But i believe you got the idea how you can do it.

Join two nodes in Firebase

I'm working on an app, which is supposed to show data from two nodes(Firebase). Firebase DB is structured as:
{
"College": {
"4F2EAB65": {
"id": "4F2EAB65",
"name": "SomeCollege"
},
"A3C2ED31": {
"id": "A3C2ED31",
"name": "OtherCollege"
},
"F967B5A0": {
"id": "F967B5A0",
"name": "CoolCollege"
}
},
"Student": {
"3E20545B": {
"college-ID": "4F2EAB65",
"id": "3E20545B",
"name": "A"
},
"6FDEE194": {
"college-ID": "F967B5A0",
"id": "6FDEE194",
"name": "B"
}
}
I want to fetch student details having details: "id", "name", "college-ID", "college-Name"(Need to fetch "college-Name" by "college-ID").
I've achieved this using for loop at front end. Is there any way to get this achieved at Firebase server, also can we make something like join (SQL).
Thanks.
There is no support for server-side joins in the Firebase Realtime Database. Client-side joins are quite normal.
The alternative is to duplicate the data upon writing, so that you don't have to read from two locations.
What's best for your application is a matter of personal preference, your comfort level with the code involved vs data duplication, and the use-cases of your app.
Client-side jons are likely not as slow as you may think. See http://stackoverflow.com/questions/35931526/speed-up-fetching-posts-for-my-social-network-app-by-using-query-instead-of-obse/35932786#35932786

Retrieving labels from multiple JIRA Subtasks via JIRA API

I am creating a reporting dashboard with the intent of getting multiple tickets/issues for a project. As most of you probably know, a JIRA issue can have subtasks. These subtasks can have labels.
I want to retrive all labels for every subtask.
I already have the project API request implemented which returns the parent ticket ids along with the issue/ticket number of all subtasks. The problem is the data returned from this request does not include the labels for the subtasks themselves.
I can loop over each subtask number and make an additional API request for each one to get the labels, however this would result in a large number of requests.
Looking through JIRA's API I cannot find a better way of doing this. Google seems to return a lot of results about plugins and version differences with Cloud vs. Server but I have not found a better solution.
Their API makes reference to an expand option but I have yet to figure out a way to make that work for subtask labels (I might be missing something obvious).
If anyone has experience with a similar situation I would appreciate hearing any advice you could offer. Thanks!
What I have currently:
Project API Request:
https://ourcompanyhere.atlassian.net/rest/api/2/search
with an additional parameter added for the JQL string of:
project=PROJECTNAME AND fixversion=version
This returns all the tickets in the project with subtasks but not the subtask labels.
I can loop over the returned data from the above request and make an additional request for each:
https://ourcompanyhere.atlassian.net/rest/api/2/issue/ticketNumberHere
JSON Response
Here is the partial JSON response back (full response is huge and I've removed key information) however this is the complete information for a ticket, with a subtask which has labels. As you can see the labels section of the subtask is completely missing.
ErrorDetail=,
Mimetype=application/json,
Statuscode=200 OK,
Filecontent= {
"expand":"schema,names",
"startAt":0,
"maxResults":50,
"total":3,
"issues":[
{
"expand":"operations,versionedRepresentations,editmeta,changelog,renderedFields",
"id":"24209",
"self":"https://[instance].atlassian.net/rest/api/latest/issue/24209",
"key":"DEV-3089",
"fields":{
"issuetype":{
"self":"https://[instance].atlassian.net/rest/api/2/issuetype/10005",
"id":"10005",
"description":"A new feature of the product, which has yet to be developed.",
"iconUrl":"https://[instance].atlassian.net/secure/viewavatar?size=xsmall&avatarId=10311&avatarType=issuetype",
"name":"New Feature",
"subtask":false,
"avatarId":10311
},
"project":{
"self":"https://[instance].atlassian.net/rest/api/2/project/10000",
"id":"10000",
"key":"DEV",
"name":"Development Queue",
"avatarUrls":{
}
},
"customfield_11000":null,
"fixVersions":[
{
"self":"https://[instance].atlassian.net/rest/api/2/version/14600",
"id":"14600",
"description":"",
"name":"",
"archived":false,
"released":true,
"releaseDate":"2017-09-15"
}
],
"resolution":{
"self":"https://[instance].atlassian.net/rest/api/2/resolution/10000",
"id":"10000",
"description":"Work has been completed on this issue.",
"name":"Done"
},
"customfield_10500":"",
"customfield_10700":null,
"customfield_10900":null,
"resolutiondate":"2017-09-15T09:19:37.000-0400",
"workratio":-1,
"watches":{
"self":"https://[instance].atlassian.net/rest/api/2/issue/DEV-3089/watchers",
"watchCount":2,
"isWatching":true
},
"lastViewed":null,
"created":"2017-05-02T10:15:08.000-0400",
"customfield_10022":null,
"customfield_10100":null,
"priority":{
"self":"https://[instance].atlassian.net/rest/api/2/priority/3",
"iconUrl":"https://[instance].atlassian.net/images/icons/priorities/medium.svg",
"name":"Medium",
"id":"3"
},
"customfield_10300":null,
"labels":[
"[label1]",
"[label2]",
"[label3]",
"[label4]",
"[label5]",
"[label6]"
],
"customfield_10016":null,
"customfield_10017":null,
"versions":[
],
"issuelinks":[
],
"assignee":{
"self":"https://[instance].atlassian.net/rest/api/2/user?username=",
"name":"[name]",
"key":"[name]",
"accountId":"[account]",
"emailAddress":"[email]",
"avatarUrls":{
},
"displayName":"[name]",
"active":true,
"timeZone":"America/New_York"
},
"updated":"2017-09-15T09:19:36.000-0400",
"status":{
"self":"https://[instance].atlassian.net/rest/api/2/status/6",
"description":"The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
"iconUrl":"https://[instance].atlassian.net/images/icons/statuses/closed.png",
"name":"Closed",
"id":"6",
"statusCategory":{
"self":"https://[instance].atlassian.net/rest/api/2/statuscategory/3",
"id":3,
"key":"done",
"colorName":"green",
"name":"Done"
}
},
"components":[
],
"description":"[description]",
"customfield_10010":null,
"customfield_10011":null,
"customfield_11100":null,
"customfield_10012":null,
"customfield_10013":null,
"customfield_10015":"",
"customfield_10005":null,
"customfield_10006":null,
"customfield_10600":null,
"customfield_10007":null,
"customfield_10008":null,
"customfield_10800":null,
"customfield_10009":null,
"summary":"[summary]",
"creator":{
"self":"https://[instance].atlassian.net/rest/api/2/user?username=",
"name":"",
"key":"",
"accountId":"",
"emailAddress":"",
"avatarUrls":{
},
"displayName":"",
"active":true,
"timeZone":"America/New_York"
},
"subtasks":[
{
"id":"30213",
"key":"DEV-4118",
"self":"https://[instance].atlassian.net/rest/api/2/issue/30213",
"fields":{
"summary":"",
"status":{
"self":"https://[instance].atlassian.net/rest/api/2/status/6",
"description":"The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
"iconUrl":"https://[instance].atlassian.net/images/icons/statuses/closed.png",
"name":"Closed",
"id":"6",
"statusCategory":{
"self":"https://[instance].atlassian.net/rest/api/2/statuscategory/3",
"id":3,
"key":"done",
"colorName":"green",
"name":"Done"
}
},
"priority":{
"self":"https://[instance].atlassian.net/rest/api/2/priority/3",
"iconUrl":"https://[instance].atlassian.net/images/icons/priorities/medium.svg",
"name":"Medium",
"id":"3"
},
"issuetype":{
"self":"https://[instance].atlassian.net/rest/api/2/issuetype/10009",
"id":"10009",
"description":"",
"iconUrl":"https://[instance].atlassian.net/secure/viewavatar?size=xsmall&avatarId=10303&avatarType=issuetype",
"name":"Testing Issue",
"subtask":true,
"avatarId":10303
}
}
}
"reporter":{
"self":"https://[instance].atlassian.net/rest/api/2/user?username=",
"name":"",
"key":"",
"accountId":"",
"emailAddress":"",
"avatarUrls":{
},
"displayName":"",
"active":true,
"timeZone":"America/New_York"
},
"customfield_10000":"2017-09-01T12:35:54.706-0400",
"customfield_10001":null,
"customfield_10200":null,
"customfield_10400":null,
"customfield_10004":null,
"environment":null,
"duedate":null,
"votes":{
"self":"https://[instance].atlassian.net/rest/api/2/issue/DEV-3089/votes",
"votes":0,
"hasVoted":false
}
}
}
]
}
Inspect the response for the /search endpoint again. On a completely empty JIRA Cloud instance I created a Project, one Issue and added a Sub-task for it. Calling the /search endpoint returns a list with two Issues (so, the Issue itself and its Sub-task) and for both there's a field called labels with an array of all the Labels attached to it.
The following is an abbreviated response with all unrelated data removed.
{
"startAt": 0,
"maxResults": 50,
"total": 2,
"issues": [
{
"key": "TEST-1",
"fields": {
"labels": []
}
},
{
"key": "TEST-2",
"fields": {
"parent": {
"key": "TEST-1"
},
"labels": [
"VOILA"
]
}
}
]
}
EDIT
After looking at the response then yes, the array in subtasks is really simple and cannot be separately expanded. You need to do the search, then parse out all the subtasks that you're interested in and either do
a separate /issue/[key] request for each one
a /search for those specific keys
After doing some further research I found a better way to do this. I'm still not getting the subtask labels back but instead of looping over each subtask and sending a separate request for each, you can do one API call using JQL like this:
https://[instance].atlassian.net/rest/api/latest/search?jql=project=[project] AND KEY IN ([comma separated list of tickets])&fields=labels'
The
&fields=labels
part drastically reduces the amount of information returned. So now I can just do a total of two calls and get everything I need. :)
Wanted to post this in case anyone runs into a similar situation.

neo4jClient create node with dynamic label using paramters

I am building an app that give users the ability to construct there own graphs. I have been using parameters for all queries and creates. But when I want to give users the ability to create a node where they can also Label it anything they want(respecting neo4j restrictions on empty string labels). How would I parameterize this type of transaction?
I tried this:
.CREATE("(a:{dynamicLabel})").WithParams(new {dynamicLabel = dlabel})...
But this yields a syntax error with neo. I am tempted to concatenate, but am worried that this may expose an injection risk to my application.
I am tempted to build up my-own class that reads the intended string and rejects any type of neo syntax, but this would limit my users a bit and I would rather not.
There is an open neo4j issue 4334, which is a feature request for adding the ability to parameterize labels during CREATE.So, this is not yet possible.
That issue contains a comment that suggests generating CREATE statements with hardcoded labels, which will work. It is, unfortunately, not as performant as using parameters (should it ever be supported in this case).
I searched like hell and finally found it out.
you can do it like that:
// create or update nodes with dynamic label from import data
WITH "file:///query.json" AS url
call apoc.load.json(url) YIELD value as u
UNWIND u.cis as ci
CALL apoc.merge.node([ ci.label ], {Id:ci.Id}, {}, {}) YIELD node
RETURN node;
The JSON looks like that:
{
"cis": [
{
"label": "Computer",
"Id": "1"
},
{
"label": "Service",
"Id": "2"
},
{
"label": "Person",
"Id": "3"
}
],
"relations": [
{
"end1Id": "1",
"Id": "4",
"end2Id": "2",
"label": "USES"
},
{
"end1Id": "3",
"Id": "5",
"end2Id": "1",
"label": "MANAGED_BY"
}
]
}
If you are using a Java client, then you can do it like this.
Node node = GraphDatabaseService.createNode();
Label label = new Label() {
#Override
public String name() {
return dynamicLabelVal;
}
};
node.addLabel(label);
You can then have a LabelCache which will avoid Label object creation for every node.

Resources