Skip to content

Commit 0c87072

Browse files
cdavernascdavernas
committed
Added new CTK features
1 parent b943a5a commit 0c87072

13 files changed

+2232
-7
lines changed

‎ctk/features/call.feature

Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
Feature: Call Task
2+
As an implementer of the workflow DSL
3+
I want to ensure that call tasks can be executed within the workflow
4+
So that my implementation conforms to the expected behavior
5+
6+
# Tests HTTP call using `content` output
7+
# Tests interpolated path parameters
8+
# Tests auto-deserialization when reading response with 'application/json' content type
9+
# Tests output filtering
10+
Scenario: Call HTTP With Content Output
11+
Given a workflow with definition:
12+
"""yaml
13+
document:
14+
dsl: 1.0.0-alpha1
15+
namespace: default
16+
name: http-call-with-content-output
17+
do:
18+
getFirstAvailablePet:
19+
call: http
20+
with:
21+
method: get
22+
endpoint:
23+
uri: https://petstore.swagger.io/v2/pet/findByStatus?status={status}
24+
output:
25+
from: .[0]
26+
"""
27+
And given the workflow input is:
28+
"""yaml
29+
status: available
30+
"""
31+
When the workflow is executed
32+
Then the workflow should complete
33+
And the workflow output should have properties 'id', 'name', 'status'
34+
35+
# Tests HTTP call using `response` output
36+
# Tests interpolated path parameters
37+
# Tests auto-deserialization when reading response with 'application/json' content type
38+
Scenario: Call HTTP With Response Output
39+
Given a workflow with definition:
40+
"""yaml
41+
document:
42+
dsl: 1.0.0-alpha1
43+
namespace: default
44+
name: http-call-with-response-output
45+
do:
46+
getPetById:
47+
call: http
48+
with:
49+
method: get
50+
endpoint:
51+
uri: https://petstore.swagger.io/v2/pet/{petId}
52+
output: response
53+
"""
54+
And given the workflow input is:
55+
"""yaml
56+
petId: 1
57+
"""
58+
When the workflow is executed
59+
Then the workflow should complete
60+
And the workflow output should have properties 'request', 'request.method', 'request.uri', 'request.headers', 'headers', 'statusCode', 'content'
61+
And the workflow output should have properties 'content.id', 'content.name', 'content.status'
62+
63+
# Tests HTTP call using `basic` authentication
64+
# Tests interpolated path parameters
65+
Scenario: Call HTTP Using Basic Authentication
66+
Given a workflow with definition:
67+
"""yaml
68+
document:
69+
dsl: 1.0.0-alpha1
70+
namespace: default
71+
name: http-call-with-basic-auth
72+
do:
73+
getSecuredEndpoint:
74+
call: http
75+
with:
76+
method: get
77+
endpoint:
78+
uri: https://httpbin.org/basic-auth/{username}/{password}
79+
authentication:
80+
basic:
81+
username: ${ .username }
82+
password: ${ .password }
83+
"""
84+
And given the workflow input is:
85+
"""yaml
86+
username: serverless-workflow
87+
password: conformance-test
88+
"""
89+
When the workflow is executed
90+
Then the workflow should complete
91+
92+
# Tests OpenAPI call using `content` output
93+
# Tests output filtering
94+
Scenario: Call OpenAPI With Content Output
95+
Given a workflow with definition:
96+
"""yaml
97+
document:
98+
dsl: 1.0.0-alpha1
99+
namespace: default
100+
name: openapi-call-with-content-output
101+
do:
102+
getPetsByStatus:
103+
call: openapi
104+
with:
105+
document:
106+
uri: https://petstore.swagger.io/v2/swagger.json
107+
operation: findPetsByStatus
108+
parameters:
109+
status: ${ .status }
110+
output:
111+
from: . | length
112+
"""
113+
And given the workflow input is:
114+
"""yaml
115+
status: available
116+
"""
117+
When the workflow is executed
118+
Then the workflow should complete
119+
120+
# Tests OpenAPI call using `response` output
121+
# Tests output filtering
122+
Scenario: Call OpenAPI With Response Output
123+
Given a workflow with definition:
124+
"""yaml
125+
document:
126+
dsl: 1.0.0-alpha1
127+
namespace: default
128+
name: openapi-call-with-response-output
129+
do:
130+
getPetById:
131+
call: openapi
132+
with:
133+
document:
134+
uri: https://petstore.swagger.io/v2/swagger.json
135+
operation: getPetById
136+
parameters:
137+
petId: ${ .petId }
138+
output: response
139+
"""
140+
And given the workflow input is:
141+
"""yaml
142+
petId: 1
143+
"""
144+
When the workflow is executed
145+
Then the workflow should complete
146+
And the workflow output should have properties 'request', 'request.method', 'request.uri', 'request.headers', 'headers', 'statusCode', 'content'
147+
And the workflow output should have properties 'content.id', 'content.name', 'content.status'

‎ctk/features/composite.feature

Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
Feature: Composite Task
2+
As an implementer of the workflow DSL
3+
I want to ensure that composite tasks can be executed within the workflow
4+
So that my implementation conforms to the expected behavior
5+
6+
# Tests composite tasks with sequential sub tasks
7+
Scenario: Composite Task With Sequential Sub Tasks
8+
Given a workflow with definition:
9+
"""yaml
10+
document:
11+
dsl: 1.0.0-alpha1
12+
namespace: default
13+
name: composite-sequential
14+
do:
15+
setRGB:
16+
execute:
17+
sequentially:
18+
setRed:
19+
set:
20+
colors: ${ .colors + ["red"] }
21+
setGreen:
22+
set:
23+
colors: ${ .colors + ["green"] }
24+
setBlue:
25+
set:
26+
colors: ${ .colors + ["blue"] }
27+
"""
28+
When the workflow is executed
29+
Then the workflow should complete with output:
30+
"""yaml
31+
colors: [ red, green, blue ]
32+
"""
33+
34+
# Tests composite tasks With competing concurrent sub tasks
35+
Scenario: Composite Task With Competing Concurrent Sub Tasks
36+
Given a workflow with definition:
37+
"""yaml
38+
document:
39+
dsl: 1.0.0-alpha1
40+
namespace: default
41+
name: composite-sequential
42+
do:
43+
setRGB:
44+
execute:
45+
concurrently:
46+
setRed:
47+
set:
48+
colors: ${ .colors + ["red"] }
49+
setGreen:
50+
set:
51+
colors: ${ .colors + ["green"] }
52+
setBlue:
53+
set:
54+
colors: ${ .colors + ["blue"] }
55+
compete: true
56+
"""
57+
When the workflow is executed
58+
Then the workflow should complete
59+
And the workflow output should have a 'colors' property containing 1 items

‎ctk/features/data-flow.feature

Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
Feature: Data Flow
2+
As an implementer of the workflow DSL
3+
I want to ensure that data flows correctly through the workflow
4+
So that my implementation conforms to the expected behavior
5+
6+
# Tests task input fileting
7+
Scenario: Input Filtering
8+
Given a workflow with definition:
9+
"""yaml
10+
document:
11+
dsl: 1.0.0-alpha1
12+
namespace: default
13+
name: output-filtering
14+
do:
15+
setUsername:
16+
input:
17+
from: .user.claims.subject #filters the input of the task, using only the user's subject
18+
set:
19+
playerId: ${ . }
20+
"""
21+
And given the workflow input is:
22+
"""yaml
23+
user:
24+
claims:
25+
subject: 6AsnRgGEB0q2O7ux9JXFAw
26+
"""
27+
When the workflow is executed
28+
Then the workflow should complete with output:
29+
"""yaml
30+
playerId: 6AsnRgGEB0q2O7ux9JXFAw
31+
"""
32+
33+
# Tests task output filtering
34+
Scenario: Output Filteing
35+
Given a workflow with definition:
36+
"""yaml
37+
document:
38+
dsl: 1.0.0-alpha1
39+
namespace: default
40+
name: output-filtering
41+
do:
42+
getPetById:
43+
call: http
44+
with:
45+
method: get
46+
endpoint:
47+
uri: https://petstore.swagger.io/v2/pet/{petId} #simple interpolation, only possible with top level variables
48+
output:
49+
from: .id #filters the output of the http call, using only the id of the returned object
50+
"""
51+
And given the workflow input is:
52+
"""yaml
53+
petId: 1
54+
"""
55+
When the workflow is executed
56+
Then the workflow should complete with output:
57+
"""yaml
58+
1
59+
"""
60+
61+
# Tests using non-object output
62+
Scenario: Use Non-object Output
63+
Given a workflow with definition:
64+
"""yaml
65+
document:
66+
dsl: 1.0.0-alpha1
67+
namespace: default
68+
name: non-object-output
69+
do:
70+
getPetById1:
71+
call: http
72+
with:
73+
method: get
74+
endpoint:
75+
uri: https://petstore.swagger.io/v2/pet/{petId} #simple interpolation, only possible with top level variables
76+
output:
77+
from: .id
78+
getPetById2:
79+
call: http
80+
with:
81+
method: get
82+
endpoint:
83+
uri: https://petstore.swagger.io/v2/pet/2
84+
output:
85+
from: '{ ids: [ $input, .id ] }'
86+
"""
87+
When the workflow is executed
88+
Then the workflow should complete with output:
89+
"""yaml
90+
ids: [ 1, 2 ]
91+
"""

‎ctk/features/emit.feature

Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
Feature: Emit Task
2+
As an implementer of the workflow DSL
3+
I want to ensure that emit tasks can be executed within the workflow
4+
So that my implementation conforms to the expected behavior
5+
6+
# Tests emit tasks
7+
Scenario: Emit Task
8+
Given a workflow with definition:
9+
"""yaml
10+
document:
11+
dsl: 1.0.0-alpha1
12+
namespace: default
13+
name: emit
14+
do:
15+
emitUserGreeted:
16+
emit:
17+
event:
18+
with:
19+
source: https://fake-source.com
20+
type: com.fake-source.user.greeted.v1
21+
data:
22+
greetings: ${ "Hello \(.user.firstName) \(.user.lastName)!" }
23+
"""
24+
And given the workflow input is:
25+
"""yaml
26+
user:
27+
firstName: John
28+
lastName: Doe
29+
"""
30+
When the workflow is executed
31+
Then the workflow should complete
32+
And the workflow output should have properties 'id', 'specversion', 'time', 'source', 'type', 'data'
33+
And the workflow output should have a 'source' property with value:
34+
"""yaml
35+
https://fake-source.com
36+
"""
37+
And the workflow output should have a 'type' property with value:
38+
"""yaml
39+
com.fake-source.user.greeted.v1
40+
"""
41+
And the workflow output should have a 'data' property with value:
42+
"""yaml
43+
greetings: Hello John Doe!
44+
"""

0 commit comments

Comments
 (0)