Breakfast Provider (LightBDD) Test Run Report

Passed: 187 (100%)100%

Test Execution Summary

Passed2026-10-25 ยท 07:55:49โ€“07:55:57 UTC
Scenarios
187
Passed
187
Failed
0
Skipped
0
Features
73
Duration
7s

CI

GitHub Actions
Build
#340
Branch
main
Commit
d2ce0e2
Repository
lemonlion/BreakfastProvider
Run
View run

Filtering

All 187 scenarios, 73 features
Status
Duration โ‰ฅ
Happy paths
Tags
Dependencies
Payloads
Apple Cinnamon Muffins Creation Feature
/muffins - Creating apple cinnamon muffins with baking profiles and toppings
A Valid Apple Cinnamon Muffin Request Should Return A Fresh Batch Happy Path 56ms🔗
Steps
✓GIVEN A valid muffin recipe with all ingredients (21ms)
✓Milk steps response message status code should be OK (0ms)
✓Eggs steps response message status code should be OK (0ms)
✓Flour steps response message status code should be OK (0ms)
✓WHEN The muffins are prepared (11ms)
✓THEN The muffin response should contain a valid batch with all ingredients (17ms)
✓AND The cow service should have received a milk request (1ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/milk" && r.Method == HttpMethod.Get ] (0ms)
Diagrams
This scenario:Payloads
Different muffin recipes should produce the expected batch 3/3 passed 159ms🔗
#Input ParametersStatusDuration
Recipe NameRecipeTemperatureDuration MinutesPan TypeExpected
1Classic
{ Ingredients: { Flour = Plain Flour, Apples = Granny Smith, Cinnamon = Ceylon }, Toppings: 2 }
{ "Ingredients": { "Flour": "Plain Flour", "Apples": "Granny Smith", "Cinnamon": "Ceylon" }, "Toppings": [ { "Name": "Streusel", "Amount": "Light" }, { "Name": "Icing Glaze", "Amount": "Drizzle" } ] }
18025Standard
ExpectedIngredientCount5
ExpectedToppingCount2
HasBakingInfoTrue
Passed82ms
2Rustic Wholesome
{ Ingredients: { Flour = Whole Wheat, Apples = Honeycrisp, Cinnamon = Cassia }, Toppings: 2 }
{ "Ingredients": { "Flour": "Whole Wheat", "Apples": "Honeycrisp", "Cinnamon": "Cassia" }, "Toppings": [ { "Name": "Brown Sugar Crumb", "Amount": "Heavy" }, { "Name": "Maple Drizzle", "Amount": "Light" } ] }
17530Cast Iron
ExpectedIngredientCount5
ExpectedToppingCount2
HasBakingInfoTrue
Passed27ms
3Spiced Deluxe
{ Ingredients: { Flour = Almond Flour, Apples = Pink Lady, Cinnamon = Saigon }, Toppings: 2 }
{ "Ingredients": { "Flour": "Almond Flour", "Apples": "Pink Lady", "Cinnamon": "Saigon" }, "Toppings": [ { "Name": "Cinnamon Sugar", "Amount": "Heavy" }, { "Name": "Cream Cheese Swirl", "Amount": "Thick" } ] }
19020Silicone
ExpectedIngredientCount5
ExpectedToppingCount2
HasBakingInfoTrue
Passed50ms
Steps
✓GIVEN A Classic muffin recipe at 180 degrees for 25 minutes in StandardMuffinRecipeTestData { Ingredients = IngredientSet { Flour = Plain Flour, Apples = Granny Smith, Cinnamon = Ceylon }, Toppings = System.Collections.Generic.List`1[BreakfastProvider.Tests.Component.Shared.Models.AppleCinnamonMuffins.ToppingData] } (14ms)
✓Milk steps response message status code should be OK (0ms)
✓Eggs steps response message status code should be OK (0ms)
✓WHEN The muffins are prepared (32ms)
✓THEN The muffin batch should match the expected param0 outcome (10ms)
✓Muffin steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Muffin steps response ingredients should have count '5' (0ms)
✓Muffin steps response toppings should have count '2' (0ms)
✓Baking temperature matches expectation should be true (0ms)
Diagrams
This scenario:Payloads
Muffins endpoint is called with an invalid field should return a bad request response 6/6 passed 219ms ยท 104ms warm-up🔗
#Input ParametersStatusDuration
ValueReasonExpected ErrorExpected StatusField
1Apples is required'Apples' is required.Bad RequestApplesPassed9ms
2Cinnamon is required'Cinnamon' is required.Bad RequestCinnamonPassed9ms
3<script>alert('xss')</script>XSS in cinnamonCinnamon contains potentially dangerous content.Bad RequestCinnamonPassed141ms
4Eggs is required'Eggs' is required.Bad RequestEggsPassed17ms
5Flour is required'Flour' is required.Bad RequestFlourPassed16ms
6Milk is required'Milk' is required.Bad RequestMilkPassed22ms
Steps
✓GIVEN A valid muffin request with an invalid field Apples set to (0ms)
✓WHEN The invalid muffin request is submitted (3ms)
✓THEN The muffin response should contain 'Apples' is required. with Bad Request (0ms)
✓Response body should contain ''Apples' is required.' (0ms)
✓Muffin steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Audit Logs Filtering Feature
/audit-logs - Filtering audit logs by entity type and entity ID
Audit Logs Should Be Filterable By Entity Id 85ms🔗
Steps
✓GIVEN An order has been created to generate an audit log (51ms)
✓A pancake batch is created (30ms)
✓Response content is valid json should be true (0ms)
✓An order is created for the batch (19ms)
✓Response content is valid json should be true (0ms)
✓WHEN Audit logs are requested filtered by entity id (20ms)
✓THEN The audit log response should contain the specific order entry (6ms)
✓The audit log response status should be ok (0ms)
✓Audit log response status code should be OK (0ms)
✓The audit logs should contain the created order (3ms)
✓Audit logs should contain [ l => l.EntityId == '3f022a87-2cf1-43ef-a039-ccb74211013c' ] (0ms)
Diagrams
This scenario:Payloads
Audit Logs Should Be Filterable By Entity Type 261ms🔗
Steps
✓GIVEN An order has been created to generate an audit log (216ms)
✓A pancake batch is created (172ms)
✓Response content is valid json should be true (0ms)
✓An order is created for the batch (40ms)
✓Response content is valid json should be true (0ms)
✓WHEN Audit logs are requested filtered by entity type (26ms)
✓THEN The audit log response should only contain order entries (15ms)
✓The audit log response status should be ok (0ms)
✓Audit log response status code should be OK (0ms)
✓The audit logs should only contain order entity type (11ms)
✓Audit logs should only contain [ l => l.EntityType == AuditLogDefaults.OrderEntityType ] (0ms)
Diagrams
This scenario:Payloads
Audit Logs Should Be Returned In Descending Timestamp Order 1.7s ยท 1.2s warm-up🔗
Steps
✓GIVEN An order has been created to generate an audit log (1.7s)
✓A pancake batch is created (385ms)
✓Response content is valid json should be true (0ms)
✓An order is created for the batch (1.3s)
✓Response content is valid json should be true (0ms)
✓WHEN Audit logs are requested filtered by entity type (69ms)
✓THEN The audit logs should be ordered by timestamp descending (10ms)
✓Audit logs should not be null or empty (0ms)
✓Audit logs should be in descending order [ l => l.Timestamp ] (0ms)
Diagrams
This scenario:Payloads
Filtering Audit Logs By A Non Existent Entity Type Should Return An Empty Collection 62ms🔗
Steps
✓WHEN Audit logs are requested filtered by a non existent entity type (35ms)
✓THEN The audit log response should be an empty collection (24ms)
✓The audit log response status should be ok (10ms)
✓Audit log response status code should be OK (0ms)
✓The audit logs list should be empty (4ms)
✓Audit logs from different time range should be empty (0ms)
Diagrams
This scenario:Payloads
Audit Logs Retrieval Feature
/audit-logs - Retrieving audit log entries for order operations
Creating An Order Should Produce A Retrievable Audit Log Entry Happy Path 137ms🔗
Steps
✓GIVEN A pancake batch has been created (26ms)
✓A pancake request is submitted with ingredients (18ms)
✓The pancake batch response should be successful (2ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Pancake steps response should not be null (0ms)
✓Pancake steps response batch id should not be empty (0ms)
✓AND An order has been created for the batch (19ms)
✓An order request is submitted (13ms)
✓The order creation response should be successful (3ms)
✓Order steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Order steps response should not be null (0ms)
✓Order steps response order id should not be empty (0ms)
✓WHEN The audit logs are retrieved (52ms)
✓THEN The audit log response should contain the order creation entry (14ms)
✓The audit log response http status should be ok (1ms)
✓Audit steps response message status code should be OK (0ms)
✓The audit log response should be valid json (5ms)
✓Response content is valid json should be true (0ms)
✓The audit log should contain an order created entry (3ms)
✓Audit steps response should contain [ a => a.Action == AuditLogDefaults.CreatedAction && a.EntityType == AuditLogDefaults.OrderEntityType && a.Details.Contains('TestCustomer_4723369103722198075') ] (0ms)
✓AND The cow service should have received a milk request (1ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/milk" && r.Method == HttpMethod.Get ] (0ms)
✓AND The kitchen service should have received a preparation request (1ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/prepare" && r.Method == HttpMethod.Post ] (0ms)
Diagrams
This scenario:Payloads
Chef Notes Management Feature
/chef-notes - Creating, retrieving, and updating chef notes (MongoDB)
Creating A Chef Note Should Return The Created Note Happy Path 11ms🔗
Steps
✓GIVEN A valid chef note request (0ms)
✓WHEN The note is submitted (4ms)
✓THEN The response should contain the created note (3ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Post steps response recipe name should be 'Recipe-6bfd545595ff457295b1aa67543e40a1' (0ms)
✓Post steps response note text should be "Remember to fold the batter gently to keep it fluffy." (0ms)
✓Post steps response category should be "Technique" (0ms)
✓Post steps response note id should not be null or empty (0ms)
Diagrams
This scenario:Payloads
Creating A Note With Missing Note Text Should Return Bad Request 9ms🔗
Steps
✓GIVEN A note request with missing note text (0ms)
✓WHEN The note is submitted (1ms)
✓THEN The note response should indicate bad request (2ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Creating A Note With Missing Recipe Name Should Return Bad Request 8ms🔗
Steps
✓GIVEN A note request with missing recipe name (0ms)
✓WHEN The note is submitted (4ms)
✓THEN The note response should indicate bad request (0ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Listing Notes By Recipe Should Return Matching Notes 56ms🔗
Steps
✓GIVEN A chef note exists (7ms)
✓A valid chef note request (0ms)
✓The note is submitted (1ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The notes are listed by recipe (38ms)
✓THEN The list response should contain the note (7ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps list response should contain [ n => n.NoteId == 'd2efbb03-51d1-439b-bdc2-2198c1d38730' ] (0ms)
Diagrams
This scenario:Payloads
Retrieving A Non Existent Note Should Return Not Found 65ms ยท 58ms warm-up🔗
Steps
✓WHEN A non existent note is retrieved (62ms)
✓THEN The get response should indicate not found (1ms)
✓Get steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Retrieving An Existing Note By Id Should Return The Note 17ms🔗
Steps
✓GIVEN A chef note exists (4ms)
✓A valid chef note request (0ms)
✓The note is submitted (1ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The note is retrieved by id (6ms)
✓THEN The get response should contain the note (5ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps response note id should be 'c77f48c2-806d-45a2-bd88-8913e31fd74b' (0ms)
✓Get steps response recipe name should be 'Recipe-13105840fd7541f2b7bf42835e49171f' (0ms)
Diagrams
This scenario:Payloads
Updating A Non Existent Note Should Return Not Found 7ms🔗
Steps
✓WHEN A non existent note is updated (4ms)
✓THEN The update response should indicate not found (1ms)
✓Patch steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Updating An Existing Note Should Return The Updated Note 506ms ยท 457ms warm-up🔗
Steps
✓GIVEN A chef note exists (181ms)
✓A valid chef note request (3ms)
✓The note is submitted (158ms)
✓The setup response should be created (12ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The note is updated (311ms)
✓THEN The update response should contain the modified note (9ms)
✓Patch steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Patch steps response note id should be 'c8b033f0-5f4b-41e8-a11f-d426f090d339' (0ms)
✓Patch steps response note text should be "Updated: Use unsalted butter for better flavour control." (0ms)
✓Patch steps response category should be "Ingredients" (0ms)
✓Patch steps response updated at should not be null (0ms)
Diagrams
This scenario:Payloads
Customer Feedback Alert Feature
PubSub โ†’ BreakfastProvider โ†’ MongoDB + gRPC + HTTP: Customer feedback event consumption and downstream processing
Consuming Customer Feedback Event Should Trigger Downstream Processing Happy Path 46ms🔗
Steps
✓GIVEN A customer feedback received event (2ms)
✓WHEN The event is published to pubsub (31ms)
✓THEN The feedback id should be generated (2ms)
✓Publish steps feedback id should not be '00000000-0000-0000-0000-000000000000' (0ms)
✓AND The supplier service should have received the feedback (3ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/ingredients/feedback" && r.Method == HttpMethod.Post ] (0ms)
Diagrams
This scenario:Payloads
Customer Preferences Management Feature
/customer-preferences - Managing customer breakfast preferences
Saving Customer Preferences Should Return The Saved Preferences Happy Path 38ms🔗
Steps
✓GIVEN A valid customer preference request (0ms)
✓WHEN The customer preferences are saved (6ms)
✓THEN The preference response should contain the saved preferences (14ms)
✓The put response http status should be ok (1ms)
✓Put steps response message status code should be OK (0ms)
✓The put response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The saved preferences should have the correct milk type (1ms)
✓Put steps response preferred milk type should be "Oat" (0ms)
✓The saved preferences should have the correct favourite item (1ms)
✓Put steps response favourite item should be "Blueberry Pancakes" (0ms)
Diagrams
This scenario:Payloads
Retrieving Existing Customer Preferences Should Return The Preferences 52ms🔗
Steps
✓GIVEN Customer preferences exist (7ms)
✓A valid customer preference request (0ms)
✓The customer preferences are saved (4ms)
✓The setup response should be ok (0ms)
✓Put steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The customer preferences are retrieved (29ms)
✓THEN The preference get response should contain the preferences (13ms)
✓The get response http status should be ok (1ms)
✓Get steps response message status code should be OK (0ms)
✓The get response should be valid json (4ms)
✓Response content is valid json should be true (0ms)
✓The retrieved preferences should match the saved preferences (2ms)
✓Get steps response customer id should be 'c503bb6cce3e43559cd89408fbd69284' (0ms)
✓Get steps response preferred milk type should be "Oat" (0ms)
✓Get steps response likes extra toppings should be true (0ms)
Diagrams
This scenario:Payloads
Retrieving Non Existent Customer Preferences Should Return Not Found 826ms ยท 812ms warm-up🔗
Steps
✓WHEN Non existent customer preferences are retrieved (822ms)
✓THEN The preference get response should indicate not found (1ms)
✓Get steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Saving Customer Preferences With Missing Customer Name Should Return Bad Request 7ms🔗
Steps
✓GIVEN A customer preference request with missing customer name (1ms)
✓WHEN The customer preferences are saved (2ms)
✓THEN The preference response should indicate bad request (1ms)
✓Put steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Updating Customer Preferences Should Return The Updated Preferences 324ms ยท 263ms warm-up🔗
Steps
✓GIVEN Customer preferences exist (292ms)
✓A valid customer preference request (2ms)
✓The customer preferences are saved (273ms)
✓The setup response should be ok (8ms)
✓Put steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The customer preferences are updated (12ms)
✓THEN The preference update response should contain the updated values (11ms)
✓The update response http status should be ok (1ms)
✓Put steps response message status code should be OK (0ms)
✓The update response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The updated preferences should have the new milk type (1ms)
✓Put steps response preferred milk type should be "Almond" (0ms)
✓The updated preferences should have the new favourite item (1ms)
✓Put steps response favourite item should be "Belgian Waffles" (0ms)
Diagrams
This scenario:Payloads
Daily Specials Idempotency Feature
/daily-specials/orders - Idempotent order creation using Idempotency-Key header
Submitting The Same Order With Different Idempotency Keys Should Return Different Confirmations 42ms🔗
Steps
✓GIVEN The cinnamon swirl order count is reset (4ms)
✓AND An order request for the same special (0ms)
✓WHEN The order is submitted with two different idempotency keys (30ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓THEN The responses should have different confirmation ids (2ms)
✓First confirmation id should not be 'da0c6532-5d49-43f5-9018-32661fbbbbbd' (0ms)
Diagrams
This scenario:Payloads
Submitting The Same Order With The Same Idempotency Key Should Return The Same Confirmation 433ms ยท 321ms warm-up🔗
Steps
✓GIVEN The cinnamon swirl order count is reset (48ms)
✓AND An order request with an idempotency key (1ms)
✓WHEN The order is submitted twice with the same idempotency key (363ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓THEN Both responses should return the same confirmation id (13ms)
✓First confirmation id should be 'fc438637-8262-454c-9a08-cbad65854a99' (0ms)
Diagrams
This scenario:Payloads
Daily Specials Not Found Feature
/daily-specials/orders - Ordering a non-existent daily special
Ordering A Non Existent Daily Special Should Return Not Found 20ms🔗
Steps
✓GIVEN A daily special order request for a non existent special (0ms)
✓WHEN The daily special order is submitted (11ms)
✓THEN The response should indicate not found (1ms)
✓Post steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Daily Specials Ordering Feature
/daily-specials - Ordering daily specials with threshold limits
A Valid Daily Special Order Should Return A Confirmation Happy Path 36ms🔗
Steps
✓GIVEN The cinnamon swirl order count is reset (18ms)
✓AND A valid daily special order request for cinnamon swirl (0ms)
✓WHEN The daily special order is submitted (2ms)
✓THEN The daily special order response should contain a valid confirmation (11ms)
✓The post response http status should be created (1ms)
✓Post steps response message status code should be Created (0ms)
✓The order response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The order response should contain the correct special id (1ms)
✓Post steps response special id should be 'aaaa0000-0000-0000-0000-000000000001' (0ms)
✓The order response should have a valid confirmation id (1ms)
✓Post steps response order confirmation id should not be empty (0ms)
Diagrams
This scenario:Payloads
Ordering A Daily Special Beyond The Threshold Should Return A Conflict Response 15ms🔗
Steps
✓GIVEN The matcha waffles order count is reset (2ms)
✓AND The matcha waffles special has been ordered up to the configured limit (3ms)
✓Post steps response message status code should be Created (0ms)
✓WHEN Another order is placed for the matcha waffles special (2ms)
✓THEN The response should indicate the daily special is sold out (1ms)
✓Post steps response message status code should be Conflict (0ms)
Diagrams
This scenario:Payloads
Remaining Quantity Should Decrease After Each Order 17ms🔗
Steps
✓GIVEN The lemon ricotta order count is reset (3ms)
✓AND A daily special order for lemon ricotta of quantity one is placed (3ms)
✓Post steps response message status code should be Created (0ms)
✓WHEN The available daily specials are requested (0ms)
✓THEN The lemon ricotta special should have one fewer remaining (4ms)
✓Response content is valid json should be true (0ms)
✓Lemon ricotta remaining quantity should be '9' (0ms)
Diagrams
This scenario:Payloads
The Daily Specials Endpoint Should Return All Available Specials 39ms🔗
Steps
✓WHEN The available daily specials are requested (19ms)
✓THEN The daily specials response should contain all expected specials (16ms)
✓The get response http status should be ok (1ms)
✓Get steps response message status code should be OK (0ms)
✓The daily specials response should be valid json (5ms)
✓Response content is valid json should be true (0ms)
✓The daily specials list should contain all expected specials (2ms)
✓Get steps response should have count ExpectedSpecialsCount (0ms)
Diagrams
This scenario:Payloads
Daily Specials Validation Feature
/daily-specials/orders - Input validation for daily special orders
Daily special order endpoint is called with invalid fields should return a bad request response 1/1 passed 25ms🔗
#Input ParametersStatusDuration
InputsOutputs
1
FieldSpecialId
Value0
ReasonQuantity must be greater than zero
ErrorMessage'Special Id' is required
ResponseStatusBad Request
Passed25ms
Steps
✓GIVEN Valid daily special order requests with an invalid field InvalidFieldFromRequest { Field = SpecialId, Value = , Reason = Special ID is required }, InvalidFieldFromRequest { Field = Quantity, Value = 0, Reason = Quantity must be greater than zero } (3ms)
✓WHEN The invalid daily special order requests are submitted (4ms)
✓THEN The responses should each contain the validation error for the invalid field VerifiableErrorResult { ErrorMessage = 'Special Id' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Quantity must be greater than zero., ResponseStatus = Bad Request } (2ms)
Diagrams
This scenario:Payloads
Equipment Readings Monitoring Feature
/equipment-readings - Recording and monitoring kitchen equipment readings (ClickHouse)
Recording An Equipment Reading Should Return The Created Record Happy Path 422ms🔗
Steps
✓GIVEN A valid equipment reading request (4ms)
✓WHEN The equipment reading is recorded (377ms)
✓THEN The reading response should contain the created record (35ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Post steps response equipment id should be 'Oven-14b36974851048cb9d0d158150595f9f' (0ms)
✓Post steps response value should be 180.5m (0ms)
✓Post steps response reading id should not be null or empty (0ms)
Diagrams
This scenario:Payloads
Deleting A Reading Should Remove It From The List 39ms🔗
Steps
✓GIVEN An equipment reading record has been created (7ms)
✓A valid equipment reading request (0ms)
✓The equipment reading is recorded (4ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The reading is deleted (20ms)
✓THEN The delete response should indicate no content (1ms)
✓Delete steps response message status code should be NoContent (0ms)
✓AND The reading should no longer be listed (7ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps list response should not contain [ r => r.ReadingId == '9b8b368f-2f90-497b-8aec-0dc7f6b62ed3' ] (0ms)
Diagrams
This scenario:Payloads
Listing Readings By Equipment Should Return Matching Records 159ms ยท 126ms warm-up🔗
Steps
✓GIVEN An equipment reading record has been created (12ms)
✓A valid equipment reading request (0ms)
✓The equipment reading is recorded (4ms)
✓The setup response should be created (2ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The readings are listed by equipment (130ms)
✓THEN The reading list response should contain the record (13ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps list response should contain [ r => r.ReadingId == '1b688019-3e7b-4a34-902a-93842bfb5fd3' ] (0ms)
Diagrams
This scenario:Payloads
Recording A Reading With Missing Metric Should Return Bad Request 21ms🔗
Steps
✓GIVEN An equipment reading request with a missing metric (1ms)
✓WHEN The equipment reading is recorded (14ms)
✓THEN The reading post response should indicate bad request (0ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Recording A Reading With Zero Value Should Return Bad Request 508ms ยท 421ms warm-up🔗
Steps
✓GIVEN An equipment reading request with zero value (29ms)
✓WHEN The equipment reading is recorded (445ms)
✓THEN The reading post response should indicate bad request (1ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Feedback Management Feature
/feedback - Submitting and retrieving customer feedback
Submitting Feedback Should Return The Created Feedback Happy Path 24ms🔗
Steps
✓GIVEN A valid feedback request (0ms)
✓WHEN The feedback is submitted (8ms)
✓THEN The feedback response should contain the created feedback (13ms)
✓The post response http status should be created (1ms)
✓Post steps response message status code should be Created (0ms)
✓The post response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The created feedback should have the correct customer name (1ms)
✓Post steps response customer name should be 'Customer-1f85de20e4a449fa80b0bc91eafcebff' (0ms)
✓The created feedback should have the correct rating (1ms)
✓Post steps response rating should be 4 (0ms)
Diagrams
This scenario:Payloads
Listing Feedback For An Order Should Return The Feedback 178ms ยท 55ms warm-up🔗
Steps
✓GIVEN A feedback entry exists (85ms)
✓A valid feedback request (1ms)
✓The feedback is submitted (67ms)
✓The setup response should be created (7ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The feedback is retrieved by order id (65ms)
✓THEN The feedback list response should contain the feedback (23ms)
✓The list response http status should be ok (1ms)
✓Get steps response message status code should be OK (0ms)
✓The list response should be valid json (6ms)
✓Response content is valid json should be true (0ms)
✓The list should contain the created feedback (9ms)
✓Get steps list response should contain [ f => f.FeedbackId == '50d63a13-0202-41ec-91d0-3be77d4f9d5f' ] (0ms)
Diagrams
This scenario:Payloads
Retrieving Existing Feedback By Id Should Return The Feedback 44ms🔗
Steps
✓GIVEN A feedback entry exists (8ms)
✓A valid feedback request (0ms)
✓The feedback is submitted (3ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The feedback is retrieved by id (23ms)
✓THEN The feedback get response should contain the feedback (9ms)
✓The get response http status should be ok (0ms)
✓Get steps response message status code should be OK (0ms)
✓The get response should be valid json (2ms)
✓Response content is valid json should be true (0ms)
✓The retrieved feedback should match the created feedback (2ms)
✓Get steps response feedback id should be '1ab1eb45-33d9-4971-94df-867d62f33304' (0ms)
✓Get steps response customer name should be 'Customer-be00b54fb1f440b7b2ef976079b798ac' (0ms)
✓Get steps response rating should be 4 (0ms)
Diagrams
This scenario:Payloads
Retrieving Non Existent Feedback Should Return Not Found 8ms🔗
Steps
✓WHEN A non existent feedback is retrieved (5ms)
✓THEN The feedback get response should indicate not found (1ms)
✓Get steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Submitting Feedback With Invalid Rating Should Return Bad Request 15ms🔗
Steps
✓GIVEN A feedback request with an invalid rating (1ms)
✓WHEN The feedback is submitted (5ms)
✓THEN The feedback response should indicate bad request (3ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Submitting Feedback With Missing Customer Name Should Return Bad Request 4ms🔗
Steps
✓GIVEN A feedback request with missing customer name (0ms)
✓WHEN The feedback is submitted (1ms)
✓THEN The feedback response should indicate bad request (0ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Grpc Order Status Feature
/grpc - Retrieving order status via gRPC
Order Status Via Grpc Should Return Order Details Happy Path 101ms🔗
Steps
✓GIVEN A pancake batch has been created (26ms)
✓A pancake request is submitted with ingredients (21ms)
✓The pancake batch response should be successful (1ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓AND An order has been created for the batch (51ms)
✓An order request is submitted (45ms)
✓The order creation response should be successful (1ms)
✓Order steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The order status is requested via grpc (8ms)
✓THEN The grpc response should contain the order details (10ms)
✓The grpc order id should match (1ms)
✓Grpc steps order status reply order id should be '6faa3945-0d40-4eaa-9f3e-5ff51e61822d' (0ms)
✓The grpc customer name should match (2ms)
✓Grpc steps order status reply customer name should be 'TestCustomer_3305383437410931492' (0ms)
✓The grpc status should be created (1ms)
✓Grpc steps order status reply status should be Created (0ms)
Diagrams
This scenario:Payloads
Order Status For Non Existent Order Should Return Not Found 43ms🔗
Steps
✓WHEN The order status for a non existent order is requested via grpc (37ms)
✓THEN The grpc response should be a not found error (4ms)
✓Grpc steps rpc exception should not be null (0ms)
✓Grpc steps rpc exception status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Grpc Recipe Summary Feature
/grpc - Retrieving recipe summaries via gRPC
Pancake Recipe Summary Should Return Correct Data Happy Path 16ms🔗
Steps
✓WHEN A recipe summary is requested for pancakes via grpc (3ms)
✓THEN The recipe summary should contain pancake data (8ms)
✓The recipe type should be Pancakes (0ms)
✓Grpc steps recipe summary reply recipe type should be 'Pancakes' (0ms)
✓The total batches should be 42 (0ms)
✓Grpc steps recipe summary reply total batches should be '42' (0ms)
✓The common ingredients should contain Milk, Flour, Eggs (2ms)
✓Grpc steps recipe summary reply common ingredients should be equivalent to '[ "Milk", "Flour", "Eggs" ]' (0ms)
Diagrams
This scenario:Payloads
Waffle Recipe Summary Should Return Correct Data Happy Path 136ms🔗
Steps
✓WHEN A recipe summary is requested for waffles via grpc (19ms)
✓THEN The recipe summary should contain waffle data (114ms)
✓The recipe type should be Waffles (1ms)
✓Grpc steps recipe summary reply recipe type should be 'Waffles' (0ms)
✓The total batches should be 28 (1ms)
✓Grpc steps recipe summary reply total batches should be '28' (0ms)
✓The common ingredients should contain Milk, Flour, Eggs, Butter (105ms)
✓Grpc steps recipe summary reply common ingredients should be equivalent to '[ "Milk", "Flour", "Eggs", "Butter" ]' (0ms)
Diagrams
This scenario:Payloads
Unknown Recipe Type Should Return Zero Batches 17ms🔗
Steps
✓WHEN A recipe summary is requested for an unknown type via grpc (3ms)
✓THEN The recipe summary should contain zero batches and no ingredients (12ms)
✓The recipe type should be Unknown (3ms)
✓Grpc steps recipe summary reply recipe type should be 'Unknown' (0ms)
✓The total batches should be 0 (0ms)
✓Grpc steps recipe summary reply total batches should be '0' (0ms)
✓The common ingredients should be empty (1ms)
✓Grpc steps recipe summary reply common ingredients should be empty (0ms)
Diagrams
This scenario:Payloads
Grpc Stream Order Updates Feature
/grpc - Streaming order updates via gRPC server streaming
Streaming Order Updates Should Return The Current Status Happy Path 101ms🔗
Steps
✓GIVEN A pancake batch has been created (20ms)
✓A pancake request is submitted with ingredients (13ms)
✓The pancake batch response should be successful (2ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓AND An order has been created for the batch (31ms)
✓An order request is submitted (25ms)
✓The order creation response should be successful (2ms)
✓Order steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN Order updates are streamed via grpc (25ms)
✓THEN The streamed response should contain the order status (20ms)
✓The stream should contain one reply (2ms)
✓Grpc steps streamed replies should have count 1 (0ms)
✓The streamed order id should match (1ms)
✓Grpc steps streamed replies[0] order id should be 'cd6df881-baed-43ab-85c2-729298ffdc85' (0ms)
✓The streamed customer name should match (1ms)
✓Grpc steps streamed replies[0] customer name should be 'TestCustomer_8221020844002029687' (0ms)
✓The streamed status should be created (1ms)
✓Grpc steps streamed replies[0] status should be Created (0ms)
Diagrams
This scenario:Payloads
Streaming Updates For Non Existent Order Should Return Not Found 11ms🔗
Steps
✓WHEN Order updates for a non existent order are streamed via grpc (4ms)
✓THEN The grpc stream should return a not found error (1ms)
✓Grpc steps rpc exception should not be null (0ms)
✓Grpc steps rpc exception status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Infrastructure Correlation Id Feature
Cross-cutting - X-Correlation-Id header propagation across API responses
A Request With A Correlation Id Should Return The Same Id In The Response Happy Path 11ms🔗
Steps
✓GIVEN A request with a known correlation id (0ms)
✓WHEN The request is sent to the menu endpoint (3ms)
✓THEN The response should contain the same correlation id (4ms)
✓Response contains correlation id header should be true (0ms)
✓First correlation id header value should be 'e2e5fba7-6e86-43eb-a662-14c3a57708ad' (0ms)
Diagrams
This scenario:Payloads
A Request Without A Correlation Id Should Have One Generated In The Response 19ms🔗
Steps
✓WHEN A request without a correlation id is sent to the menu endpoint (13ms)
✓THEN The response should contain a generated correlation id (1ms)
✓Response contains correlation id header should be true (0ms)
✓First correlation id header value should not be null or empty (0ms)
Diagrams
This scenario:Payloads
Infrastructure Degraded Health Check Feature
/health - Health check endpoint reporting degraded status when downstream services are unavailable
Health Check Should Report Degraded When Multiple Downstream Services Are Unavailable 245ms🔗
Steps
✓GIVEN The cow service is configured to be unreachable (0ms)
✓AND The supplier service is configured to be unreachable (0ms)
✓WHEN The health check endpoint is called (212ms)
✓THEN The health check response should indicate a degraded status (14ms)
✓The health check response status should be ok (1ms)
✓Health response status code should be OK (0ms)
✓The health check response should be valid json (7ms)
✓Health check result should not be null (0ms)
✓The overall status should be degraded (1ms)
✓Health check result status should be Degraded (0ms)
✓AND The cow service dependency should report degraded (7ms)
✓Health check result results should contain key CowService (0ms)
✓Health check result results[ health check names cow service] status should be Degraded (0ms)
✓AND The supplier service dependency should report degraded (1ms)
✓Health check result results should contain key SupplierService (0ms)
✓Health check result results[ health check names supplier service] status should be Degraded (0ms)
Diagrams
This scenario:Payloads
Health Check Should Report Degraded When The Cow Service Is Unavailable 173ms🔗
Steps
✓GIVEN The cow service is configured to be unreachable (0ms)
✓WHEN The health check endpoint is called (164ms)
✓THEN The health check response should indicate a degraded status (4ms)
✓The health check response status should be ok (0ms)
✓Health response status code should be OK (0ms)
✓The health check response should be valid json (0ms)
✓Health check result should not be null (0ms)
✓The overall status should be degraded (0ms)
✓Health check result status should be Degraded (0ms)
✓AND The cow service dependency should report degraded (0ms)
✓Health check result results should contain key CowService (0ms)
✓Health check result results[ health check names cow service] status should be Degraded (0ms)
Diagrams
This scenario:Payloads
Infrastructure Downstream Error Health Check Feature
/health - Health check reports degraded when a downstream service returns a non-success HTTP status
Health Check Should Report Degraded When A Downstream Service Returns A Non Success Status 239ms🔗
Steps
✓GIVEN The kitchen service health check is configured to use a failing endpoint (1ms)
✓WHEN The health check endpoint is called (209ms)
✓THEN The health check response should indicate a degraded status (19ms)
✓The health check response status should be ok (1ms)
✓Health response status code should be OK (0ms)
✓The health check response should be valid json (6ms)
✓Health check result should not be null (0ms)
✓The overall status should be degraded (1ms)
✓Health check result status should be Degraded (0ms)
✓AND The kitchen service dependency should report degraded with a status code description (4ms)
✓Health check result results should contain key KitchenService (0ms)
✓Kitchen service health status should be Degraded (0ms)
✓Kitchen service health description should contain "503" (0ms)
Diagrams
This scenario:Payloads
Infrastructure Header Propagation Feature
/milk; /menu - X-Correlation-Id header propagation to downstream services
A Request With A Correlation Id Should Forward It To The Cow Service Happy Path 41ms🔗
Steps
✓GIVEN A request with a known correlation id (1ms)
✓WHEN Milk is requested from the milk endpoint (30ms)
✓THEN The cow service should have received the correlation id (4ms)
✓Requests should not be empty (0ms)
✓Request headers should contain key CorrelationId (0ms)
✓Request headers[ custom headers correlation id] should be '72f95490-0a43-4e39-a547-b535a2611f0b' (0ms)
Diagrams
This scenario:Payloads
A Request With A Correlation Id Should Forward It To The Supplier Service 87ms🔗
Steps
✓GIVEN A request with a known correlation id (0ms)
✓AND The menu cache is cleared (50ms)
✓WHEN The menu is requested (30ms)
✓THEN The supplier service should have received the correlation id (2ms)
✓Requests should not be empty (0ms)
✓Request headers should contain key CorrelationId (0ms)
✓Request headers[ custom headers correlation id] should be '6762738b-9d11-4b7d-b844-fc0fa9c39d37' (0ms)
Diagrams
This scenario:Payloads
Infrastructure Health Check Detail Feature
/health - Health check response includes detailed entry descriptions and data
The Health Check Response Should Include Description And Data For Each Entry 47ms🔗
Steps
✓WHEN The health check endpoint is called (8ms)
✓THEN The health check response should contain detailed entries (37ms)
Diagrams
This scenario:Payloads
Infrastructure Health Check Feature
/health - Health check endpoint with dependency status for monitoring
The Health Check Endpoint Should Return A Healthy Status With Dependency Details Happy Path 91ms🔗
Steps
✓WHEN The health check endpoint is called (10ms)
✓THEN The health check response should indicate healthy with all dependencies (75ms)
Diagrams
This scenario:Payloads
Infrastructure Heartbeat Feature
/ - Heartbeat endpoint confirming the service is running
The Heartbeat Endpoint Should Return A Running Message Happy Path 19ms🔗
Steps
✓WHEN The heartbeat endpoint is called (5ms)
✓THEN The heartbeat response should indicate the service is running (11ms)
✓The heartbeat response status should be ok (1ms)
✓Heartbeat response status code should be OK (0ms)
✓The heartbeat response should be valid json (3ms)
✓Heartbeat result should not be null (0ms)
✓The heartbeat status should be ok (1ms)
✓Heartbeat result status should be HeartbeatStatus (0ms)
Diagrams
This scenario:Payloads
Infrastructure Telemetry Feature
/orders - Structured logging and telemetry verification
Creating An Order Should Emit A Structured Log Entry Happy Path 448ms🔗
Steps
✓GIVEN The application is configured with an in memory log capture (196ms)
✓AND A pancake batch has been created (184ms)
✓A pancake request is submitted with ingredients (176ms)
✓The pancake batch should be successful (2ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓AND A valid order request (1ms)
✓WHEN The order is submitted (44ms)
✓Order steps response message status code should be Created (0ms)
✓THEN A structured log entry should have been captured for order creation (16ms)
✓The log should contain an order created message (7ms)
✓Log provider entries should contain [ e => e.Message.Contains("created for customer") ] (0ms)
✓The log message should include the customer name (2ms)
✓Log provider entries should contain [ e => e.Message.Contains('TelemetryTest_5437561125936435448') ] (0ms)
✓The log message should include the item count (2ms)
✓Log provider entries should contain [ e => e.Message.Contains("1 items") ] (0ms)
Diagrams
This scenario:Payloads
Ingredient Usage Analytics Feature
/ingredient-usage - Recording and summarising ingredient usage (BigQuery)
Recording Ingredient Usage Should Return The Created Record Happy Path 12ms🔗
Steps
✓GIVEN A valid ingredient usage request (0ms)
✓WHEN The usage is recorded (2ms)
✓THEN The response should contain the created record (5ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Post steps response ingredient name should be 'Flour-9f8638585a1b4346920074a97f33391f' (0ms)
✓Post steps response quantity used should be 2.5m (0ms)
✓Post steps response usage id should not be null or empty (0ms)
Diagrams
This scenario:Payloads
Getting Usage Summary Should Return Aggregated Data 87ms🔗
Steps
✓GIVEN An ingredient usage record exists (6ms)
✓A valid ingredient usage request (0ms)
✓The usage is recorded (3ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The summary is requested (67ms)
✓THEN The summary should contain aggregated data (9ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps summary response should contain [ s => s.IngredientName == 'Flour-28c7e5f234064ebeb88455dbc18a65b6' ] (0ms)
Diagrams
This scenario:Payloads
Listing Usage By Ingredient Should Return Matching Records 620ms ยท 195ms warm-up🔗
Steps
✓GIVEN An ingredient usage record exists (218ms)
✓A valid ingredient usage request (1ms)
✓The usage is recorded (201ms)
✓The setup response should be created (9ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The usage is listed by ingredient (389ms)
✓THEN The list response should contain the record (8ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps list response should contain [ u => u.IngredientName == 'Flour-baf1085c60944a31864f7adb68fdf808' ] (0ms)
Diagrams
This scenario:Payloads
Recording Usage With Missing Ingredient Name Should Return Bad Request 11ms🔗
Steps
✓GIVEN A usage request with missing ingredient name (1ms)
✓WHEN The usage is recorded (5ms)
✓THEN The usage response should indicate bad request (2ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Recording Usage With Zero Quantity Should Return Bad Request 11ms🔗
Steps
✓GIVEN A usage request with zero quantity (1ms)
✓WHEN The usage is recorded (3ms)
✓THEN The usage response should indicate bad request (1ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Ingredient Waste Tracking Feature
/ingredient-waste - Recording and managing ingredient waste (BigQuery)
Recording Ingredient Waste Should Return The Created Record Happy Path 12ms🔗
Steps
✓GIVEN A valid ingredient waste request (0ms)
✓WHEN The waste is recorded (4ms)
✓THEN The response should contain the created waste record (4ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Post steps response ingredient name should not be null or empty (0ms)
✓Post steps response quantity wasted should be 0.5m (0ms)
✓Post steps response waste id should not be null or empty (0ms)
✓Post steps response reason should be "Expired before use" (0ms)
Diagrams
This scenario:Payloads
Deleting A Waste Record Should Return No Content 485ms🔗
Steps
✓GIVEN An ingredient waste record exists (114ms)
✓A valid ingredient waste request (2ms)
✓The waste is recorded (95ms)
✓The setup response should be created (11ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The waste record is deleted (362ms)
✓THEN The delete response should indicate no content (1ms)
✓Delete steps response message status code should be NoContent (0ms)
Diagrams
This scenario:Payloads
Listing Waste By Recipe Should Return Matching Records 52ms🔗
Steps
✓GIVEN An ingredient waste record exists (8ms)
✓A valid ingredient waste request (0ms)
✓The waste is recorded (4ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The waste is listed by recipe (31ms)
✓THEN The list response should contain the waste record (7ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps list response should contain [ w => w.WasteId == '78af33d7-d5f3-475b-be2c-c77bc2d123ee' ] (0ms)
Diagrams
This scenario:Payloads
Recording Waste With Missing Ingredient Name Should Return Bad Request 7ms🔗
Steps
✓GIVEN A waste request with missing ingredient name (1ms)
✓WHEN The waste is recorded (2ms)
✓THEN The waste response should indicate bad request (0ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Recording Waste With Missing Reason Should Return Bad Request 6ms🔗
Steps
✓GIVEN A waste request with missing reason (1ms)
✓WHEN The waste is recorded (1ms)
✓THEN The waste response should indicate bad request (0ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Recording Waste With Zero Quantity Should Return Bad Request 88ms ยท 76ms warm-up🔗
Steps
✓GIVEN A waste request with zero quantity (1ms)
✓WHEN The waste is recorded (81ms)
✓THEN The waste response should indicate bad request (1ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Ingredients Goat Milk Downstream Failure Feature
/goat-milk - Handling downstream Goat Service failures
Requesting Goat Milk When The Goat Service Is Unavailable Should Return A Bad Gateway Response 47ms🔗
Steps
✓GIVEN The goat service will return service unavailable (1ms)
✓WHEN Goat milk is requested (33ms)
✓THEN The goat milk response should indicate a bad gateway (8ms)
✓The goat milk response http status should be bad gateway (2ms)
✓Goat milk steps response message status code should be BadGateway (0ms)
✓The goat milk error should indicate goat service unavailable (2ms)
✓Goat milk error response body should contain GoatServiceUnavailableTitle (0ms)
Diagrams
This scenario:Payloads
Requesting Goat Milk When The Goat Service Returns An Invalid Response Should Return A Bad Gateway Response 12ms🔗
Steps
✓GIVEN The goat service will return an invalid response (3ms)
✓WHEN Goat milk is requested (4ms)
✓THEN The goat milk response should indicate a bad gateway (2ms)
✓The goat milk response http status should be bad gateway (0ms)
✓Goat milk steps response message status code should be BadGateway (0ms)
✓The goat milk error should indicate goat service unavailable (0ms)
✓Goat milk error response body should contain GoatServiceUnavailableTitle (0ms)
Diagrams
This scenario:Payloads
Ingredients Goat Milk Feature Flag Feature
/goat-milk - Goat milk availability controlled by feature flag
Goat Milk Endpoint Should Return Fresh Goat Milk When Feature Is Enabled 276ms🔗
Steps
✓GIVEN The goat milk feature flag is enabled (175ms)
✓WHEN Goat milk is requested (70ms)
✓THEN The goat milk response should contain fresh goat milk (27ms)
✓The goat milk response http status should be ok (2ms)
✓Goat milk steps response message status code should be OK (0ms)
✓The goat milk should be fresh (2ms)
✓Goat milk steps goat milk response goat milk should be FreshGoatMilk (0ms)
Diagrams
This scenario:Payloads
Goat Milk Endpoint Should Return Not Found When Feature Is Disabled 188ms🔗
Steps
✓GIVEN The goat milk feature flag is disabled (140ms)
✓WHEN Goat milk is requested (35ms)
✓THEN The goat milk response should indicate feature disabled (6ms)
✓The goat milk response http status should be not found (1ms)
✓Goat milk steps response message status code should be NotFound (0ms)
✓The goat milk error should indicate feature disabled (2ms)
✓Goat milk feature disabled response body should contain FeatureDisabled (0ms)
Diagrams
This scenario:Payloads
Ingredients Goat Milk Sourcing Feature
/goat-milk - Sourcing goat milk from the Goat Service
The Goat Milk Endpoint Should Return Fresh Goat Milk From The Goat Service Happy Path 47ms🔗
Steps
✓WHEN Goat milk is requested (10ms)
✓THEN The goat milk response should contain fresh goat milk (17ms)
✓The goat milk response http status should be ok (1ms)
✓Goat milk steps response message status code should be OK (0ms)
✓The goat milk response should be valid json (1ms)
✓Goat milk steps goat milk response should not be null (0ms)
✓The goat milk should be fresh (2ms)
✓Goat milk steps goat milk response goat milk should be FreshGoatMilk (0ms)
✓AND The goat service should have received a goat milk request (8ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/goat-milk" && r.Method == HttpMethod.Get ] (0ms)
Diagrams
This scenario:Payloads
Ingredients Milk Downstream Failure Feature
/milk - Handling downstream Cow Service failures
Requesting Milk When The Cow Service Is Unavailable Should Return A Bad Gateway Response 9ms🔗
Steps
✓GIVEN The cow service will return service unavailable (0ms)
✓WHEN Milk is requested (2ms)
✓THEN The milk response should indicate a bad gateway (2ms)
✓The milk response http status should be bad gateway (0ms)
✓Milk steps response message status code should be BadGateway (0ms)
✓The milk error should indicate cow service unavailable (0ms)
✓Milk error response body should contain CowServiceUnavailableTitle (0ms)
Diagrams
This scenario:Payloads
Requesting Milk When The Cow Service Returns An Invalid Response Should Return A Bad Gateway Response 38ms🔗
Steps
✓GIVEN The cow service will return an invalid response (0ms)
✓WHEN Milk is requested (2ms)
✓THEN The milk response should indicate a bad gateway (28ms)
✓The milk response http status should be bad gateway (0ms)
✓Milk steps response message status code should be BadGateway (0ms)
✓The milk error should indicate cow service unavailable (0ms)
✓Milk error response body should contain CowServiceUnavailableTitle (0ms)
Diagrams
This scenario:Payloads
Requesting Milk When The Cow Service Times Out Should Return A Bad Gateway Response 19ms🔗
Steps
✓GIVEN The cow service will return a timeout (1ms)
✓WHEN Milk is requested (5ms)
✓THEN The milk response should indicate a bad gateway (10ms)
✓The milk response http status should be bad gateway (1ms)
✓Milk steps response message status code should be BadGateway (0ms)
✓The milk error should indicate cow service unavailable (2ms)
✓Milk error response body should contain CowServiceUnavailableTitle (0ms)
Diagrams
This scenario:Payloads
Inventory Management Feature
/inventory - Managing ingredient inventory with full CRUD operations
Adding A New Inventory Item Should Return The Created Item Happy Path 26ms🔗
Steps
✓GIVEN A valid inventory item request (0ms)
✓WHEN The inventory item is submitted (4ms)
✓THEN The inventory response should contain the created item (13ms)
✓The post response http status should be created (1ms)
✓Post steps response message status code should be Created (0ms)
✓The post response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The created item should have the correct name (2ms)
✓Post steps response name should be 'Flour-99ff610b6cd347bd979b4bcd1dc40361' (0ms)
✓The created item should have the correct category (1ms)
✓Post steps response category should be "Dry Goods" (0ms)
Diagrams
This scenario:Payloads
Deleting An Inventory Item Should Return No Content 65ms🔗
Steps
✓GIVEN An inventory item exists (11ms)
✓A valid inventory item request (0ms)
✓The inventory item is submitted (3ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The inventory item is deleted (45ms)
✓THEN The inventory delete response should indicate no content (1ms)
✓Delete steps response message status code should be NoContent (0ms)
Diagrams
This scenario:Payloads
Listing All Inventory Items Should Return All Items 73ms🔗
Steps
✓GIVEN An inventory item exists (5ms)
✓A valid inventory item request (0ms)
✓The inventory item is submitted (2ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN All inventory items are requested (48ms)
✓THEN The inventory list response should contain the item (16ms)
✓The list response http status should be ok (1ms)
✓Get steps response message status code should be OK (0ms)
✓The list response should be valid json (4ms)
✓Response content is valid json should be true (0ms)
✓The list should contain the created item (4ms)
✓Get steps list response should contain [ i => i.Id == '4' ] (0ms)
Diagrams
This scenario:Payloads
Retrieving A Non Existent Inventory Item Should Return Not Found 21ms🔗
Steps
✓WHEN A non existent inventory item is retrieved (15ms)
✓THEN The inventory get response should indicate not found (1ms)
✓Get steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Retrieving An Existing Inventory Item Should Return The Item 219ms ยท 107ms warm-up🔗
Steps
✓GIVEN An inventory item exists (127ms)
✓A valid inventory item request (1ms)
✓The inventory item is submitted (112ms)
✓The setup response should be created (7ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The inventory item is retrieved by id (71ms)
✓THEN The inventory get response should contain the item (18ms)
✓The get response http status should be ok (1ms)
✓Get steps response message status code should be OK (0ms)
✓The get response should be valid json (4ms)
✓Response content is valid json should be true (0ms)
✓The retrieved item should match the created item (6ms)
✓Get steps response id should be '1' (0ms)
✓Get steps response name should be 'Flour-b185b860159f4ffcb9d7471bbda4e8c5' (0ms)
Diagrams
This scenario:Payloads
Updating An Inventory Item Should Return The Updated Item 146ms🔗
Steps
✓GIVEN An inventory item exists (15ms)
✓A valid inventory item request (1ms)
✓The inventory item is submitted (6ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The inventory item is updated (101ms)
✓THEN The inventory update response should contain the updated values (23ms)
✓The put response http status should be ok (1ms)
✓Put steps response message status code should be OK (0ms)
✓The put response should be valid json (9ms)
✓Response content is valid json should be true (0ms)
✓The updated item should have the new category (3ms)
✓Put steps response category should be "Updated Category" (0ms)
Diagrams
This scenario:Payloads
Menu Availability Feature
/menu - Retrieving the breakfast menu with ingredient availability
The Menu Endpoint Should Return All Menu Items With Availability Happy Path 103ms🔗
Steps
✓WHEN The menu is requested (60ms)
✓THEN The menu response should contain all menu items (18ms)
✓AND The menu items should be in alphabetical order (6ms)
✓Response content is valid json should be true (0ms)
✓Menu steps response should be in ascending order [ m => m.Name ] (0ms)
✓AND The supplier service should have received an availability request (6ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath.Contains("/availability") && r.Method == HttpMethod.Get ] (0ms)
Diagrams
This scenario:Payloads
Menu Caching Feature
/menu - Menu response caching behaviour
The Menu Should Return Cached Results On Subsequent Requests 97ms🔗
Steps
✓GIVEN The menu has been requested and cached (73ms)
✓The menu cache is cleared (19ms)
✓The first menu request is sent (21ms)
✓The first menu response should be successful (28ms)
✓Menu steps response message status code should be OK (0ms)
✓AND The supplier service is then made unavailable (3ms)
✓WHEN The menu is requested again (7ms)
✓THEN The menu response should still return available items (8ms)
✓The cached menu response http status should be ok (1ms)
✓Second menu steps response message status code should be OK (0ms)
✓The cached menu list should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The cached menu should contain available items (1ms)
✓Second menu steps response should contain [ m => m.IsAvailable ] (0ms)
Diagrams
This scenario:Payloads
Menu Downstream Failure Feature
/menu - Handling downstream Supplier Service failures
Requesting The Menu When The Supplier Service Is Unavailable Should Mark Items As Unavailable 89ms🔗
Steps
✓GIVEN The supplier service will return service unavailable (17ms)
✓WHEN The menu is requested (43ms)
✓THEN The menu response should mark all items as unavailable (23ms)
✓The menu response http status should be ok (6ms)
✓Menu steps response message status code should be OK (0ms)
✓The menu list should be valid json (4ms)
✓Response content is valid json should be true (0ms)
✓All menu items should be marked as unavailable (2ms)
✓Menu steps response should only contain [ m => m.IsAvailable == false ] (0ms)
Diagrams
This scenario:Payloads
Order Timings Analytics Feature
/order-timings - Recording and summarising kitchen order timings (ClickHouse)
Recording An Order Timing Should Return The Created Record Happy Path 51ms🔗
Steps
✓GIVEN A valid order timing request (1ms)
✓WHEN The order timing is recorded (39ms)
✓THEN The timing response should contain the created record (7ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Post steps response station should be 'Griddle-2749c1cc49e94cd788c6812d959c82c2' (0ms)
✓Post steps response prep seconds should be 42.5m (0ms)
✓Post steps response timing id should not be null or empty (0ms)
Diagrams
This scenario:Payloads
Getting The Timing Summary Should Return Aggregated Data 67ms🔗
Steps
✓GIVEN An order timing record has been created (7ms)
✓A valid order timing request (0ms)
✓The order timing is recorded (4ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The timing summary is requested (47ms)
✓THEN The summary should contain aggregated data for the station (9ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps summary response should contain [ s => s.Station == 'Griddle-3d0e85642c994fa5a8e435b79d89d6b2' && s.TimingCount >= 1 ] (0ms)
Diagrams
This scenario:Payloads
Listing Timings By Station Should Return Matching Records 52ms🔗
Steps
✓GIVEN An order timing record has been created (12ms)
✓A valid order timing request (0ms)
✓The order timing is recorded (5ms)
✓The setup response should be created (1ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The timings are listed by station (30ms)
✓THEN The timing list response should contain the record (7ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps list response should contain [ t => t.TimingId == 'a29437c1-52b8-4adc-82d8-3d113dc1daf2' ] (0ms)
Diagrams
This scenario:Payloads
Recording A Timing With Missing Station Should Return Bad Request 5ms🔗
Steps
✓GIVEN An order timing request with a missing station (0ms)
✓WHEN The order timing is recorded (1ms)
✓THEN The timing post response should indicate bad request (0ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Recording A Timing With Zero Prep Seconds Should Return Bad Request 6ms🔗
Steps
✓GIVEN An order timing request with zero prep seconds (1ms)
✓WHEN The order timing is recorded (1ms)
✓THEN The timing post response should indicate bad request (1ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Orders Breakfast Order Feature
/orders - Creating and managing breakfast orders with event publishing
A Valid Order Should Be Created And An Event Published Happy Path 675ms🔗
Steps
✓GIVEN A pancake batch has been created (45ms)
✓AND A valid order request for the created batch (0ms)
✓WHEN The breakfast order is placed (14ms)
✓THEN The order response should contain a complete order (4ms)
✓The order response http status should be created (0ms)
✓Order steps response message status code should be Created (0ms)
✓The order response should be valid json (0ms)
✓Response content is valid json should be true (0ms)
✓The order should contain the customer name (0ms)
✓Order steps response customer name should be 'TestCustomer_6453592761845257628' (0ms)
✓The order should contain the ordered items (0ms)
✓Order steps response items should have count 1 (0ms)
✓AND An order created event should have been published (601ms)
✓AND The kitchen service should have received a preparation request (1ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/prepare" && r.Method == HttpMethod.Post ] (0ms)
Diagrams
This scenario:Payloads
Creating An Order Should Produce An Audit Log Entry And Events 704ms🔗
Steps
✓GIVEN A pancake batch has been created (38ms)
✓AND A valid order request for the created batch (0ms)
✓WHEN The breakfast order is placed (11ms)
✓THEN The order response should contain a complete order (12ms)
✓The order response http status should be created (1ms)
✓Order steps response message status code should be Created (0ms)
✓The order response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The order should contain the customer name (1ms)
✓Order steps response customer name should be 'TestCustomer_3610822396445621331' (0ms)
✓The order should contain the ordered items (1ms)
✓Order steps response items should have count 1 (0ms)
✓AND An order created event should have been published (621ms)
✓AND A recipe log should have been published to kafka (12ms)
Diagrams
This scenario:Payloads
Creating An Order Should Write An Outbox Message That Gets Processed 144ms🔗
Steps
✓GIVEN A pancake batch has been created (39ms)
✓AND A valid order request for the created batch (0ms)
✓WHEN The breakfast order is placed (9ms)
✓THEN The order response should contain a complete order (5ms)
✓The order response http status should be created (0ms)
✓Order steps response message status code should be Created (0ms)
✓The order response should be valid json (0ms)
✓Response content is valid json should be true (0ms)
✓The order should contain the customer name (0ms)
✓Order steps response customer name should be 'TestCustomer_6601233861193812443' (0ms)
✓The order should contain the ordered items (0ms)
✓Order steps response items should have count 1 (0ms)
✓AND An outbox message should have been written for the order created event (43ms)
✓Outbox messages should contain [ m => m.EventType == 'OrderCreatedEvent', $"an outbox message should exist for event type '{eventType}'" ] (0ms)
✓AND The outbox message should have been processed (40ms)
Diagrams
This scenario:Payloads
Orders Complete Lifecycle Feature
/orders - Complete order lifecycle from creation through to completion
An Order Should Progress Through All Status Transitions To Completion Happy Path 290ms🔗
Steps
✓GIVEN A pancake batch has been created (45ms)
✓AND A breakfast order has been placed for the batch (26ms)
✓An order request is submitted for the pancake batch (15ms)
✓The order creation response should be successful (5ms)
✓Order steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Order steps response should not be null (0ms)
✓The order id is captured from the order response (1ms)
✓Order id should not be empty (0ms)
✓WHEN The order is progressed through the complete lifecycle (80ms)
✓The order status is updated to preparing (10ms)
✓The preparing transition should succeed (1ms)
✓Patch steps response message status code should be OK (0ms)
✓The order status is updated to ready (4ms)
✓The ready transition should succeed (1ms)
✓Patch steps response message status code should be OK (0ms)
✓The order status is updated to completed (4ms)
✓The completed transition should succeed (1ms)
✓Patch steps response message status code should be OK (0ms)
✓THEN The completed order should be retrievable with all details (38ms)
✓AND The order timestamps should be recent (6ms)
✓Retrieval steps response created at should be close to '10/25/2026 07:55:57', '00:02:00' (0ms)
✓AND The order id should be a valid guid format (3ms)
✓Retrieval steps response order id should match regex @"^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$" (0ms)
✓AND An audit log entry should exist for the order (62ms)
✓Audit logs are retrieved for the order (26ms)
✓Audit log response status code should be OK (0ms)
✓The audit logs should contain the order creation entry (24ms)
✓Audit logs should contain [ l => l.EntityId == 'c8a06f1f-eff5-4bbc-9c8a-7ddbc33b8fd8' && l.Action == AuditLogDefaults.CreatedAction ] (0ms)
✓AND The cow service should have received a milk request (5ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/milk" && r.Method == HttpMethod.Get ] (0ms)
✓AND The kitchen service should have received a preparation request (6ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/prepare" && r.Method == HttpMethod.Post ] (0ms)
Diagrams
This scenario:Payloads
Orders Cross Field Validation Feature
/orders - Cross-field validation with configurable item limits
An Order At The Maximum Items Per Order Should Be Accepted 2.7s ยท 1.4s warm-up🔗
Steps
✓GIVEN The maximum items per order is configured to two (236ms)
✓AND A pancake batch has been created (1.2s)
✓A pancake request is submitted with ingredients (1.2s)
✓The pancake batch should be successful (2ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓AND An order request with two items (1ms)
✓WHEN The order is submitted (1.2s)
✓THEN The response should indicate success (2ms)
✓Order steps response message status code should be Created (0ms)
Diagrams
This scenario:Payloads
An Order Exceeding The Maximum Items Per Order Should Be Rejected 290ms🔗
Steps
✓GIVEN The maximum items per order is configured to two (151ms)
✓AND A pancake batch has been created (87ms)
✓A pancake request is submitted with ingredients (84ms)
✓The pancake batch should be successful (0ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓AND An order request with three items (1ms)
✓WHEN The order is submitted (22ms)
✓THEN The response should indicate a validation error (4ms)
✓The order response status should be bad request (1ms)
✓Order steps response message status code should be BadRequest (0ms)
✓AND The error message should reference the item limit (13ms)
✓Order validation errors should contain [ e => e.Contains("cannot contain more than 2 items") ] (0ms)
Diagrams
This scenario:Payloads
Orders Kitchen Service Failure Feature
/orders - Creating orders when the Kitchen Service returns an error
Creating An Order When The Kitchen Service Returns An Error Should Still Create The Order 75ms🔗
Steps
✓GIVEN A pancake batch has been created (35ms)
✓AND A valid order request for the created batch (4ms)
✓AND The kitchen service will return an error (0ms)
✓WHEN The breakfast order is placed (12ms)
✓THEN The order should still be created successfully (9ms)
✓The order response http status should be created (1ms)
✓Order steps response message status code should be Created (0ms)
✓The order response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The order should contain the customer name (1ms)
✓Order steps response customer name should be 'TestCustomer_6970296540110359673' (0ms)
✓AND The order should be retrievable by its id (3ms)
✓Get order steps response message status code should be OK (0ms)
Diagrams
This scenario:Payloads
Orders Order Retrieval Feature
/orders - Retrieving breakfast orders by ID
A Previously Created Order Should Be Retrievable By Id Happy Path 95ms🔗
Steps
✓GIVEN A pancake batch has been created (22ms)
✓A pancake request is submitted with ingredients (14ms)
✓The pancake batch response should be successful (2ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Pancake steps response should not be null (0ms)
✓Pancake steps response batch id should not be empty (0ms)
✓AND An order has been created for the batch (21ms)
✓An order request is submitted (14ms)
✓The order creation response should be successful (3ms)
✓Order steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Order steps response should not be null (0ms)
✓Order steps response order id should not be empty (0ms)
✓WHEN The order is retrieved by id (1ms)
✓THEN The retrieved order should match the created order (31ms)
✓AND The cow service should have received a milk request (1ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/milk" && r.Method == HttpMethod.Get ] (0ms)
✓AND The kitchen service should have received a preparation request (1ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/prepare" && r.Method == HttpMethod.Post ] (0ms)
Diagrams
This scenario:Payloads
Retrieving A Non Existent Order Should Return Not Found 31ms🔗
Steps
✓GIVEN A non existent order id (0ms)
✓WHEN The order is retrieved by id (24ms)
✓THEN The response should be not found (2ms)
✓Retrieval steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Orders Outbox Retry Exhaustion Feature
/orders - Outbox message transitions to failed after exhausting retries
An Outbox Message Should Transition To Failed After Exhausting Retries 1.0s🔗
Steps
✓GIVEN A pending outbox message with a test specific destination (6ms)
✓THEN The outbox message should transition to failed (1.0s)
Diagrams
This scenario:Payloads
Orders Pagination Feature
/orders - Paginated listing of breakfast orders
Listing Orders Should Return A Paginated Response Happy Path 199ms🔗
Steps
✓GIVEN Multiple orders have been created (129ms)
✓A pancake batch is created (89ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Two orders are created for the batch (38ms)
✓Order steps response message status code should be Created (0ms)
✓Order steps response message status code should be Created (0ms)
✓WHEN Orders are listed with default pagination (38ms)
✓THEN The paginated response should contain the correct metadata (28ms)
Diagrams
This scenario:Payloads
Listing Orders When None Exist Should Return An Empty Page 76ms🔗
Steps
✓WHEN Orders are listed with default pagination (33ms)
✓THEN The paginated response should be empty (39ms)
✓The list response should be ok (1ms)
✓List steps response message status code should be OK (0ms)
✓The list response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The items list should be empty (1ms)
✓List steps response items should be empty (0ms)
✓The total count should be zero (27ms)
✓List steps response total count should be 0 (0ms)
Diagrams
This scenario:Payloads
Listing Orders With A Small Page Size Should Limit Results 226ms🔗
Steps
✓GIVEN Multiple orders have been created (149ms)
✓A pancake batch is created (74ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Two orders are created for the batch (71ms)
✓Order steps response message status code should be Created (0ms)
✓Order steps response message status code should be Created (0ms)
✓WHEN Orders are listed with a page size of one (58ms)
✓THEN The paginated response should contain only one item (10ms)
✓List steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓List steps response items should have count 1 (0ms)
✓AND The total pages should reflect the full order count (2ms)
✓List steps response total pages should be greater than or equal to '2' (0ms)
Diagrams
This scenario:Payloads
Requesting The Second Page Should Return Different Orders 128ms🔗
Steps
✓GIVEN Multiple orders have been created (99ms)
✓A pancake batch is created (57ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Two orders are created for the batch (39ms)
✓Order steps response message status code should be Created (0ms)
✓Order steps response message status code should be Created (0ms)
✓WHEN The second page of orders is requested with a page size of one (23ms)
✓THEN The paginated response should contain only one item (0ms)
✓List steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓List steps response items should have count 1 (0ms)
✓AND The page number should be two (1ms)
✓List steps response page should be 2 (0ms)
Diagrams
This scenario:Payloads
Orders Rate Limiting Feature
/orders - Rate limiting on order creation
Exceeding The Rate Limit Should Return Too Many Requests 320ms🔗
Steps
✓GIVEN The rate limit is configured to allow one request per window (147ms)
✓AND A pancake batch has been created (123ms)
✓A pancake request is submitted with ingredients (117ms)
✓The pancake batch should be successful (1ms)
✓Pancake steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓AND A valid order request (1ms)
✓WHEN The order is submitted twice in rapid succession (31ms)
✓THEN The first request should succeed (1ms)
✓First response status code should be Created (0ms)
✓AND The second request should be rate limited (1ms)
✓Second response status code should be TooManyRequests (0ms)
Diagrams
This scenario:Payloads
Orders Status Transition Feature
/orders - Order status transitions following the order lifecycle
A valid status transition should update the order 4/4 passed 212ms🔗
#Input ParametersStatusDuration
From StatusTo Status
1CreatedCancelledPassed41ms
2CreatedPreparingPassed44ms
3PreparingReadyPassed37ms
4ReadyCompletedPassed89ms
Steps
✓GIVEN An order exists with status Created (25ms)
✓A pancake batch is created (9ms)
✓Response content is valid json should be true (0ms)
✓An order is created for the batch (9ms)
✓Response content is valid json should be true (0ms)
✓The order is transitioned to Created (0ms)
✓WHEN The order status is updated to Cancelled (3ms)
✓THEN The order should be updated successfully to Cancelled (3ms)
✓The patch response http status should be ok (0ms)
✓Patch steps response message status code should be OK (0ms)
✓The updated order status should be Cancelled (0ms)
✓Response content is valid json should be true (0ms)
✓Patch steps response status should be 'Cancelled' (0ms)
Diagrams
This scenario:Payloads
An invalid status transition should return a conflict response 7/7 passed 312ms🔗
#Input ParametersStatusDuration
From StatusTo Status
1CancelledPreparingPassed37ms
2CancelledReadyPassed31ms
3CompletedPreparingPassed40ms
4CreatedCompletedPassed36ms
5CreatedReadyPassed38ms
6PreparingCancelledPassed61ms
7ReadyPreparingPassed66ms
Steps
✓GIVEN An order exists with status Cancelled (30ms)
✓A pancake batch is created (10ms)
✓Response content is valid json should be true (0ms)
✓An order is created for the batch (10ms)
✓Response content is valid json should be true (0ms)
✓The order is transitioned to Cancelled (3ms)
✓Patch steps response message status code should be OK (0ms)
✓WHEN The order status is updated to Preparing (1ms)
✓THEN The response should indicate an invalid state transition (0ms)
✓Patch steps response message status code should be Conflict (0ms)
Diagrams
This scenario:Payloads
Orders Status Update Not Found Feature
/orders - Updating the status of a non-existent order
Updating The Status Of A Non Existent Order Should Return Not Found 9ms🔗
Steps
✓GIVEN A non existent order id (0ms)
✓WHEN The order status is updated to preparing (3ms)
✓THEN The response should indicate not found (1ms)
✓Patch steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Orders Validation Feature
/orders - Input validation for order creation and status updates
Order status update endpoint is called with invalid fields should return a bad request response 1/1 passed 45ms🔗
#Input ParametersStatusDuration
InputsOutputs
1
FieldStatus
Valuenull
ReasonStatus is required
ErrorMessage'Status' is required
ResponseStatusBad Request
Passed45ms
Steps
✓GIVEN Valid status update requests with an invalid field InvalidFieldFromRequest { Field = Status, Value = , Reason = Status is required } (8ms)
✓WHEN The invalid status update requests are submitted (30ms)
✓THEN The status update responses should each contain the validation error for the invalid field VerifiableErrorResult { ErrorMessage = 'Status' is required., ResponseStatus = Bad Request } (2ms)
Diagrams
This scenario:Payloads
Orders endpoint is called with invalid fields should return a bad request response 1/1 passed 90ms🔗
#Input ParametersStatusDuration
InputsOutputs
1
FieldCustomerName
Value0
ReasonQuantity must be greater than zero
ErrorMessage'Customer Name' is required
ResponseStatusBad Request
Passed90ms
Steps
✓GIVEN Valid order requests with an invalid field InvalidFieldFromRequest { Field = CustomerName, Value = , Reason = Customer name is required }, InvalidFieldFromRequest { Field = Items, Value = , Reason = At least one item is required }, InvalidFieldFromRequest { Field = Items[0].ItemType, Value = , Reason = Item type is required }, InvalidFieldFromRequest { Field = Items[0].BatchId, Value = , Reason = Batch ID is required }, InvalidFieldFromRequest { Field = Items[0].Quantity, Value = 0, Reason = Quantity must be greater than zero } (23ms)
✓WHEN The invalid order requests are submitted (55ms)
✓THEN The responses should each contain the validation error for the invalid field VerifiableErrorResult { ErrorMessage = 'Customer Name' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = The Items field is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Item Type' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Batch Id' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Quantity must be greater than zero., ResponseStatus = Bad Request } (2ms)
Diagrams
This scenario:Payloads
Pancakes Content Negotiation Feature
/pancakes - Content negotiation and unsupported media types
Sending a request with an unsupported content type should return an unsupported media type response 3/3 passed 349ms ยท 177ms warm-up🔗
#Input ParametersStatusDuration
Content Type
1application/xmlPassed22ms
2text/htmlPassed18ms
3text/plainPassed308ms
Steps
✓GIVEN A pancake request with content type application/xml (0ms)
✓WHEN The pancakes are prepared (0ms)
✓THEN The response should indicate unsupported media type (0ms)
✓Response status code should be UnsupportedMediaType (0ms)
Diagrams
This scenario:Payloads
Pancakes Creation Feature
/pancakes - Creating pancakes with ingredients and optional toppings
A Valid Pancake Request Should Return A Fresh Batch Happy Path 150ms🔗
Steps
✓GIVEN A valid pancake recipe with all ingredients (75ms)
✓WHEN The pancakes are prepared (12ms)
✓THEN The pancakes response should contain a valid batch with all ingredients (33ms)
✓AND The cow service should have received a milk request (24ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/milk" && r.Method == HttpMethod.Get ] (0ms)
Diagrams
This scenario:Payloads
A Pancake Request With More Toppings Than Allowed Should Return A Bad Request Response 54ms🔗
Steps
✓GIVEN The max toppings per item is 5 (4ms)
✓AND A valid pancake recipe with all ingredients (26ms)
✓AND The request has more toppings than the configured limit (3ms)
✓WHEN The pancakes are prepared (1ms)
✓THEN The pancakes response should indicate too many toppings (9ms)
✓The response http status should be bad request (1ms)
✓Pancake steps response message status code should be BadRequest (0ms)
✓The response should contain max toppings error (4ms)
✓Pancake error response body should contain MaxToppingsExceeded (0ms)
Diagrams
This scenario:Payloads
Pancakes endpoint is called with invalid ingredients should return a bad request response 1/1 passed 114ms🔗
#Input ParametersStatusDuration
InputsOutputs
1
FieldMilk
Valuejavascript:void(0)
ReasonXSS in eggs
ErrorMessage'Milk' is required
ResponseStatusBad Request
Passed114ms
Steps
✓GIVEN Valid pancake requests with an invalid field InvalidFieldFromRequest { Field = Milk, Value = , Reason = Milk is required }, InvalidFieldFromRequest { Field = Flour, Value = , Reason = Flour is required }, InvalidFieldFromRequest { Field = Eggs, Value = , Reason = Eggs is required }, InvalidFieldFromRequest { Field = Milk, Value = <script>alert</script>, Reason = XSS in milk }, InvalidFieldFromRequest { Field = Flour, Value = <img onerror=x>, Reason = XSS in flour }, InvalidFieldFromRequest { Field = Eggs, Value = javascript:void(0), Reason = XSS in eggs } (19ms)
✓WHEN The invalid pancake requests are submitted (41ms)
✓THEN The responses should each contain the validation error for the invalid field VerifiableErrorResult { ErrorMessage = 'Milk' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Flour' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Eggs' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Milk contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Flour contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Eggs contains potentially dangerous content., ResponseStatus = Bad Request } (14ms)
Diagrams
This scenario:Payloads
Recipe Costs Analysis Feature
Kafka โ†’ BreakfastProvider โ†’ BigQuery + gRPC + HTTP: Recipe cost event consumption and downstream processing
Consuming Recipe Cost Event Should Trigger Downstream Processing Happy Path 46ms🔗
Steps
✓GIVEN A recipe cost calculated event (1ms)
✓WHEN The event is published to kafka (34ms)
✓THEN The calculation id should be generated (3ms)
✓Publish steps calculation id should not be '00000000-0000-0000-0000-000000000000' (0ms)
✓AND The kitchen service should have received the preparation request (3ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/prepare" && r.Method == HttpMethod.Post ] (0ms)
Diagrams
This scenario:Payloads
Recipe Reviews Management Feature
/recipe-reviews - Submitting and retrieving recipe reviews (MongoDB)
Submitting A Recipe Review Should Return The Created Review Happy Path 121ms ยท 81ms warm-up🔗
Steps
✓GIVEN A valid recipe review request (2ms)
✓WHEN The review is submitted (86ms)
✓THEN The review response should contain the created review (30ms)
✓The post response http status should be created (1ms)
✓Post steps response message status code should be Created (0ms)
✓The post response should be valid json (12ms)
✓Response content is valid json should be true (0ms)
✓The created review should have the correct recipe name (2ms)
✓Post steps response recipe name should be 'Recipe-78a6ce3534084af29cfb6fe40172bab8' (0ms)
✓The created review should have the correct rating (1ms)
✓Post steps response rating should be 5 (0ms)
Diagrams
This scenario:Payloads
Listing Reviews By Recipe Should Return Matching Reviews 44ms🔗
Steps
✓GIVEN A review entry exists (4ms)
✓A valid recipe review request (0ms)
✓The review is submitted (1ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The reviews are listed by recipe (28ms)
✓THEN The review list response should contain the review (8ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps list response should contain [ r => r.ReviewId == '13a15bd0-cc3a-4112-95ac-ce2356d2f658' ] (0ms)
Diagrams
This scenario:Payloads
Retrieving Existing Review By Id Should Return The Review 28ms🔗
Steps
✓GIVEN A review entry exists (8ms)
✓A valid recipe review request (0ms)
✓The review is submitted (1ms)
✓The setup response should be created (2ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The review is retrieved by id (9ms)
✓THEN The review get response should contain the review (6ms)
✓Get steps response message status code should be OK (0ms)
✓Response content is valid json should be true (0ms)
✓Get steps response review id should be 'd1400c75-2613-448f-8384-e38f454bacde' (0ms)
✓Get steps response recipe name should be 'Recipe-5a331a842c9c466b9853825e5da105c8' (0ms)
Diagrams
This scenario:Payloads
Retrieving Non Existent Review Should Return Not Found 28ms🔗
Steps
✓WHEN A non existent review is retrieved (24ms)
✓THEN The review get response should indicate not found (2ms)
✓Get steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Submitting Review With Invalid Rating Should Return Bad Request 12ms🔗
Steps
✓GIVEN A review request with an invalid rating (0ms)
✓WHEN The review is submitted (4ms)
✓THEN The review response should indicate bad request (1ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Submitting Review With Missing Recipe Name Should Return Bad Request 6ms🔗
Steps
✓GIVEN A review request with missing recipe name (1ms)
✓WHEN The review is submitted (2ms)
✓THEN The review response should indicate bad request (0ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Reporting Batch Completions Feature
/graphql - Querying batch completion records populated by Pub/Sub consumption
Batch Completions Should Contain Data Ingested Via PubSub Consumer Happy Path 140ms🔗
Steps
✓GIVEN A pancake batch has been created (88ms)
✓WHEN The batch completions are queried via graphql (25ms)
✓THEN The graphql response should contain the batch completion record (24ms)
✓The batch completions response should be successful (1ms)
✓Graph ql steps response message status code should be OK (0ms)
✓The batch completions response should be valid json (9ms)
✓The batch completions should contain the pancake batch (7ms)
✓Graph ql steps batch completions should contain [ r => r.BatchId == 'ec6a522c-6954-4e6b-974b-0cefab71dfed' && r.RecipeType == "Pancakes" && r.Ingredients.Contains("Milk") ] (0ms)
Diagrams
This scenario:Payloads
Reporting Equipment Alerts Feature
/graphql - Querying equipment alerts populated by Event Hub consumption
Equipment Alerts Should Contain Data Ingested Via Event Hub Consumer Happy Path 121ms🔗
Steps
✓GIVEN A pancake batch has been created (46ms)
✓WHEN The equipment alerts are queried via graphql (37ms)
✓THEN The graphql response should contain the equipment alert record (32ms)
✓The equipment alerts response should be successful (1ms)
✓Graph ql steps response message status code should be OK (0ms)
✓The equipment alerts response should be valid json (13ms)
✓The equipment alerts should contain the pancake batch alert (11ms)
✓Graph ql steps equipment alerts should contain [ a => a.BatchId == '3d872790-31ca-4762-bedc-68c170eda19a' && a.EquipmentName == "Griddle" && a.AlertType == "UsageCycleCompleted" ] (0ms)
Diagrams
This scenario:Payloads
Reporting Event Grid Webhook Feature
/webhooks/eventgrid - Receiving and processing EventGrid webhook events
Ingredient Shipments Should Be Recorded When Delivered Via EventGrid Webhook Happy Path 122ms🔗
Steps
✓GIVEN An ingredient delivery event has been received via eventgrid webhook (88ms)
✓An ingredient delivery event is posted to the webhook (82ms)
✓The webhook response should be successful (1ms)
✓Webhook response status code should be OK (0ms)
✓WHEN The ingredient shipments are queried via graphql (14ms)
✓THEN The graphql response should contain the ingredient shipment (16ms)
✓The ingredient shipments response should be successful (1ms)
✓Graph ql steps response message status code should be OK (0ms)
✓The ingredient shipments response should be valid json (4ms)
✓The ingredient shipments should contain the delivery (6ms)
✓Graph ql steps ingredient shipments should contain [ s => s.DeliveryId == '311836f0-933e-43e4-887c-65d3fd6fd681' && s.IngredientName == "Milk" && s.Quantity == 50.0m ] (0ms)
Diagrams
This scenario:Payloads
Reporting Order Summaries Feature
/graphql - Querying order summary reports via GraphQL
Order Summaries Should Contain Ingested Order Data Happy Path 144ms🔗
Steps
✓GIVEN A pancake batch has been created (84ms)
✓AND A breakfast order has been placed for the batch (28ms)
✓An order request is submitted for the pancake batch (14ms)
✓The order creation response should be successful (3ms)
✓Order steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓Order steps response should not be null (0ms)
✓The order id is captured from the order response (1ms)
✓Order id should not be empty (0ms)
✓WHEN The order summaries are queried via graphql (5ms)
✓THEN The graphql response should contain the ingested order summary (16ms)
✓The graphql response should be successful (0ms)
✓Graph ql steps response message status code should be OK (0ms)
✓The order summaries response should be valid json (2ms)
✓The order summaries should contain the test order (8ms)
✓Graph ql steps order summaries should contain [ o => o.OrderId == '81dad0de-15fa-433f-bccb-6752f54bc3fa' && o.CustomerName == 'TestCustomer_4851304452853372594' && o.ItemCount == 1 && o.TableNumber == 7 ] (0ms)
Diagrams
This scenario:Payloads
Order Summaries Should Return An Empty List When No Orders Exist 38ms🔗
Steps
✓WHEN The order summaries are queried via graphql (15ms)
✓THEN The graphql response should be successful (1ms)
✓Graph ql steps response message status code should be OK (0ms)
✓AND The order summaries list should be empty or not contain the test order (17ms)
✓Graph ql steps order summaries should not contain [ o => o.OrderId == '00000000-0000-0000-0000-000000000000' ] (0ms)
Diagrams
This scenario:Payloads
Reporting Recipe Reports Feature
/graphql - Querying recipe reports and aggregations via GraphQL
Recipe Reports Should Contain Ingested Recipe Data Happy Path 249ms🔗
Steps
✓GIVEN A pancake batch has been created (104ms)
✓WHEN The recipe reports are queried via graphql (119ms)
✓THEN The graphql response should contain the ingested recipe reports (21ms)
✓The recipe reports response should be successful (1ms)
✓Graph ql steps response message status code should be OK (0ms)
✓The recipe reports response should be valid json (7ms)
✓The recipe reports should contain the pancake entry (6ms)
✓Graph ql steps recipe reports should contain [ r => r.OrderId == 'ae436af8-25c7-4b5b-942b-c392f71eaf0d' && r.RecipeType == "Pancakes" && r.Ingredients.Contains("Milk") ] (0ms)
Diagrams
This scenario:Payloads
Ingredient Usage Should Aggregate Across Multiple Recipes 73ms🔗
Steps
✓GIVEN Multiple recipe logs have been ingested with overlapping ingredients (10ms)
✓A pancake recipe is seeded with common ingredients (3ms)
✓A waffle recipe is seeded with overlapping ingredients (3ms)
✓WHEN The ingredient usage is queried via graphql (35ms)
✓THEN The ingredient usage should reflect aggregated counts (23ms)
✓The ingredient usage response should be successful (1ms)
✓Graph ql steps response message status code should be OK (0ms)
✓The ingredient usage response should be valid json (5ms)
✓Milk should appear in two recipes (3ms)
✓Graph ql steps ingredient usage should contain [ i => i.Ingredient == "Milk" && i.Count >= 2 ] (0ms)
✓Butter should appear in one recipe (5ms)
✓Graph ql steps ingredient usage should contain [ i => i.Ingredient == "Butter" && i.Count >= 1 ] (0ms)
Diagrams
This scenario:Payloads
Reservations Management Feature
/reservations - Managing table reservations with full CRUD operations and cancellation
Creating A Reservation Should Return The Confirmed Reservation Happy Path 226ms ยท 169ms warm-up🔗
Steps
✓GIVEN A valid reservation request (4ms)
✓WHEN The reservation is submitted (182ms)
✓THEN The reservation response should contain the confirmed booking (34ms)
✓The post response http status should be created (4ms)
✓Post steps response message status code should be Created (0ms)
✓The post response should be valid json (16ms)
✓Response content is valid json should be true (0ms)
✓The reservation status should be confirmed (1ms)
✓Post steps response status should be "Confirmed" (0ms)
✓The reservation customer name should match (5ms)
✓Post steps response customer name should be 'Customer-e6673dd4a1b14262bf767513cd517f16' (0ms)
Diagrams
This scenario:Payloads
Cancelling A Reservation Should Return The Cancelled Reservation 72ms🔗
Steps
✓GIVEN A reservation exists (6ms)
✓A valid reservation request (0ms)
✓The reservation is submitted (3ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The reservation is cancelled (47ms)
✓THEN The cancellation response should indicate the reservation is cancelled (12ms)
✓The cancel response http status should be ok (1ms)
✓Cancel steps response message status code should be OK (0ms)
✓The cancel response should be valid json (4ms)
✓Response content is valid json should be true (0ms)
✓The cancelled reservation status should be cancelled (3ms)
✓Cancel steps response status should be "Cancelled" (0ms)
Diagrams
This scenario:Payloads
Cancelling An Already Cancelled Reservation Should Return A Conflict Response 58ms🔗
Steps
✓GIVEN A cancelled reservation exists (43ms)
✓A valid reservation request (0ms)
✓The reservation is submitted (7ms)
✓The setup response should be created (2ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓The reservation is cancelled for setup (10ms)
✓The setup cancellation should succeed (6ms)
✓Cancel steps response message status code should be OK (0ms)
✓WHEN The reservation is cancelled again (5ms)
✓THEN The cancellation response should indicate a conflict (3ms)
✓Cancel steps response message status code should be Conflict (0ms)
Diagrams
This scenario:Payloads
Deleting A Reservation Should Return No Content 48ms🔗
Steps
✓GIVEN A reservation exists (11ms)
✓A valid reservation request (0ms)
✓The reservation is submitted (7ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The reservation is deleted (32ms)
✓THEN The reservation delete response should indicate no content (1ms)
✓Delete response status code should be NoContent (0ms)
Diagrams
This scenario:Payloads
Retrieving An Existing Reservation Should Return The Reservation 119ms🔗
Steps
✓GIVEN A reservation exists (53ms)
✓A valid reservation request (1ms)
✓The reservation is submitted (34ms)
✓The setup response should be created (7ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The reservation is retrieved by id (38ms)
✓THEN The reservation get response should contain the reservation (21ms)
✓The get response http status should be ok (3ms)
✓Get steps response message status code should be OK (0ms)
✓The get response should be valid json (7ms)
✓Response content is valid json should be true (0ms)
✓The retrieved reservation should match the created booking (3ms)
✓Get steps response id should be '2' (0ms)
✓Get steps response customer name should be 'Customer-841d94ea0501492280c1c688a84ac9c5' (0ms)
✓Get steps response status should be "Confirmed" (0ms)
Diagrams
This scenario:Payloads
Service Times Analysis Feature
Order served events - Service time analysis (Kafka โ†’ ClickHouse โ†’ gRPC โ†’ Kitchen)
Consuming An Order Served Event Should Trigger Downstream Processing Happy Path 63ms🔗
Steps
✓GIVEN An order served event (3ms)
✓WHEN The event is published to kafka (42ms)
✓THEN The order id should be generated (2ms)
✓Publish steps order id should not be '00000000-0000-0000-0000-000000000000' (0ms)
✓AND The kitchen service should have received the status request (7ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == $"/status/{orderId}" && r.Method == HttpMethod.Get ] (0ms)
Diagrams
This scenario:Payloads
Specifications Async Api Feature
/asyncapi/v1.json - Serving the AsyncAPI specification describing event-driven messaging
The AsyncApi Endpoint Should Return A Valid Specification Happy Path 717ms🔗
Steps
✓WHEN The asyncapi endpoint is called (583ms)
✓THEN The response should be valid (49ms)
✓The response status should be ok (1ms)
✓Async api response status code should be OK (0ms)
✓The response should be valid json (44ms)
✓Async api response is valid json should be true $"response body (first 500 chars): {_asyncApiJsonString?[..Math.Min(_asyncApiJsonString.Length, 500)]}" (0ms)
✓AND The asyncapi spec is written to disk (57ms)
Diagrams
This scenario:Payloads
Specifications Async Api UI Feature
/asyncapi - Serving the AsyncAPI documentation UI
The AsyncApi UI Endpoint Should Return A Valid Page Happy Path 20ms🔗
Steps
✓WHEN The asyncapi ui endpoint is called (4ms)
✓THEN The response should be a valid asyncapi page (13ms)
✓The response status should be ok (1ms)
✓Document steps response message status code should be OK (0ms)
✓The response should be valid html (1ms)
✓Document steps body should contain "<html" (0ms)
✓The page should render the document with AsyncApiStandalone (1ms)
✓Document steps body should contain 'AsyncApiStandalone' (0ms)
✓The page should render the document at /asyncapi/v1.json (1ms)
✓Document steps body should contain '/asyncapi/v1.json' (0ms)
Diagrams
This scenario:Payloads
Specifications Graph QL Schema Feature
/graphql/schema.json; /graphql/schema.graphql - Serving the GraphQL schema as introspection JSON and as a schema definition
The GraphQL Schema Definition Endpoint Should Return The Schema Definition Happy Path 185ms🔗
Steps
✓WHEN The graphql schema definition endpoint is called (117ms)
✓THEN The response should be a graphql schema definition (10ms)
✓The response status should be ok (3ms)
✓Document steps response message status code should be OK (0ms)
✓The response content type should be CONTENT TYPE application/graphql (2ms)
✓Document steps response message content headers content type media type should be 'application/graphql' (0ms)
✓AND The schema definition should declare all the reporting queries (47ms)
✓AND The graphql schema definition is written to disk (3ms)schema.graphql
Diagrams
This scenario:Payloads
The GraphQL Schema Endpoint Should Return A Valid Specification Happy Path 125ms🔗
Steps
✓WHEN The graphql schema endpoint is called (67ms)
✓THEN The response should be valid (6ms)
✓The response status should be ok (0ms)
✓Document steps response message status code should be OK (0ms)
✓The response should be valid json (2ms)
✓Document steps json should not be null (0ms)
✓AND The schema should contain all the reporting queries (25ms)
✓AND The reporting queries should be documented (12ms)
✓The query type should carry a description (3ms)
✓Graph ql schema documents type description(_document steps json, graph ql schema defaults query type name) should not be null or white space (0ms)
✓Every query should carry a description (5ms)
✓Graph ql schema documents undocumented fields(_document steps json, graph ql schema defaults query type name) should be empty (0ms)
✓AND The graphql schema is written to disk (3ms)graphql.json
Diagrams
This scenario:Payloads
Specifications Graph QL UI Feature
/graphql/ - Serving the Nitro GraphQL IDE
The GraphQL UI Endpoint Should Return A Valid Page Happy Path 37ms🔗
Steps
✓WHEN The graphql ui endpoint is called (23ms)
✓THEN The response should be a valid nitro page (8ms)
✓The response status should be ok (1ms)
✓Document steps response message status code should be OK (0ms)
✓The response should be valid html (1ms)
✓Document steps body should contain "<html" (0ms)
✓The page should be the Nitro ide (1ms)
✓Document steps body should contain 'Nitro' (0ms)
✓AND The page should be served by the service itself (1ms)
✓Document steps response message headers contains( graph ql schema defaults cdn ray header) should be false (0ms)
Diagrams
This scenario:Payloads
Specifications Grpc Contract Feature
/grpc/v1.json; /grpc/protos/breakfast.proto - Serving the gRPC contract as a descriptor set and as its proto file
The Grpc Contract Endpoint Should Return A Valid Specification Happy Path 110ms🔗
Steps
✓WHEN The grpc contract endpoint is called (18ms)
✓THEN The response should be valid (45ms)
✓The response status should be ok (0ms)
✓Document steps response message status code should be OK (0ms)
✓The response should be a valid descriptor set (41ms)
✓Document steps descriptor set should not be null (0ms)
✓AND The grpc contract should describe the breakfast service (35ms)
✓AND Every breakfast method should be documented (3ms)
✓Grpc descriptor comments undocumented methods( contract file, grpc contract defaults service name) should be empty (0ms)
✓AND The grpc contract is written to disk (2ms)grpc.json
Diagrams
This scenario:Payloads
The Grpc Proto Endpoint Should Return The Proto File Happy Path 39ms🔗
Steps
✓WHEN The grpc proto endpoint is called (5ms)
✓THEN The response should be a plain text proto file (6ms)
✓The response status should be ok (1ms)
✓Document steps response message status code should be OK (0ms)
✓The response content type should be CONTENT TYPE text/plain (1ms)
✓Document steps response message content headers content type media type should be 'text/plain' (0ms)
✓AND The proto file should declare the breakfast service (7ms)
✓The proto file should declare the breakfast package (1ms)
✓Document steps body should contain 'package breakfast;' (0ms)
✓The proto file should declare the BreakfastGrpc service (2ms)
✓Document steps body should contain 'service BreakfastGrpc' (0ms)
Diagrams
This scenario:Payloads
Specifications Grpc Reflection Feature
gRPC server reflection - Letting gRPC tools discover the breakfast service
Grpc Server Reflection Should Describe The Breakfast Service Happy Path 100ms🔗
Steps
✓WHEN The breakfast service is described through grpc server reflection (57ms)
✓THEN The description should be the breakfast proto file (21ms)
✓The description should hold the breakfast.proto file (10ms)
✓Reflection steps described files should contain single [ f => f.Name == 'breakfast.proto' ] (0ms)
✓The described file should be in the breakfast package (2ms)
✓Described file package should be 'breakfast' (0ms)
✓AND The description should contain every breakfast method (17ms)
Diagrams
This scenario:Payloads
Grpc Server Reflection Should List The Breakfast Service Happy Path 247ms🔗
Steps
✓WHEN The services are listed through grpc server reflection (231ms)
✓THEN The breakfast service should be listed (1ms)
✓Reflection steps listed services should contain ServiceFullName (0ms)
✓AND The reflection service should be listed (1ms)
✓Reflection steps listed services should contain ReflectionServiceFullName (0ms)
Diagrams
This scenario:Payloads
Specifications Grpc UI Feature
/grpc/ - Serving the gRPC documentation page
The Grpc UI Endpoint Should Return A Page Describing The Service Happy Path 89ms🔗
Steps
✓WHEN The grpc ui endpoint is called (55ms)
✓THEN The response should be a valid grpc documentation page (8ms)
✓The response status should be ok (1ms)
✓Document steps response message status code should be OK (0ms)
✓The response content type should be CONTENT TYPE text/html (1ms)
✓Document steps response message content headers content type media type should be 'text/html' (0ms)
✓The response should be valid html (1ms)
✓Document steps body should contain "<html" (0ms)
✓AND The page should describe every breakfast method (12ms)
✓AND The page should link to the grpc contract (5ms)
✓The page should link to v1.json (1ms)
✓Document steps body should contain 'href="v1.json"' (0ms)
✓The page should link to protos/breakfast.proto (0ms)
✓Document steps body should contain 'href="protos/breakfast.proto"' (0ms)
✓AND The grpc ui page is written to disk (3ms)grpc.html
Diagrams
This scenario:Payloads
Specifications Open Api Feature
/openapi/v1.json - Serving the OpenAPI specification describing all REST endpoints
The OpenApi Endpoint Should Return A Valid Specification Happy Path 655ms🔗
Steps
✓WHEN The open api endpoint is called (560ms)
✓THEN The response should be valid (44ms)
✓The response status should be ok (1ms)
✓Swagger response status code should be OK (0ms)
✓The response should be valid json (9ms)
✓Open api response is valid json should be true (0ms)
✓AND The response should contain all the endpoints (35ms)
✓AND The openapi spec is written to disk (11ms)
✓The openapi spec is written to disk as json (7ms)openapi.json
Diagrams
This scenario:Payloads
Specifications Open Api Scalar UI Feature
/scalar/v1 - Serving the interactive API documentation UI powered by Scalar
The Scalar UI Endpoint Should Return A Valid Page Happy Path 349ms🔗
Steps
✓WHEN The scalar ui endpoint is called (335ms)
✓THEN The response should be a valid scalar page (11ms)
✓The response status should be ok (2ms)
✓Scalar response status code should be OK (0ms)
✓The response should be valid html (2ms)
✓Scalar ui response body should contain "<html" (0ms)
✓The response should refer to scalar (1ms)
✓Scalar ui response body should contain "scalar" (0ms)
Diagrams
This scenario:Payloads
Staff Management Feature
/staff - Managing kitchen staff members with full CRUD operations
Adding A New Staff Member Should Return The Created Member Happy Path 18ms🔗
Steps
✓GIVEN A valid staff member request (0ms)
✓WHEN The staff member is submitted (4ms)
✓THEN The staff response should contain the created member (11ms)
✓The post response http status should be created (1ms)
✓Post steps response message status code should be Created (0ms)
✓The post response should be valid json (1ms)
✓Response content is valid json should be true (0ms)
✓The created member should have the correct name (1ms)
✓Post steps response name should be 'Chef-d032b0774c3e4a81ab775c30db53468c' (0ms)
✓The created member should have the correct role (1ms)
✓Post steps response role should be "Chef" (0ms)
Diagrams
This scenario:Payloads
Adding A Staff Member With An Invalid Role Should Return A Bad Request Response 7ms🔗
Steps
✓GIVEN A staff member request with an invalid role (1ms)
✓WHEN The staff member is submitted (2ms)
✓THEN The staff response should indicate bad request (1ms)
✓Post steps response message status code should be BadRequest (0ms)
Diagrams
This scenario:Payloads
Deleting A Staff Member Should Return No Content 149ms ยท 85ms warm-up🔗
Steps
✓GIVEN A staff member exists (103ms)
✓A valid staff member request (2ms)
✓The staff member is submitted (90ms)
✓The setup response should be created (6ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The staff member is deleted (41ms)
✓THEN The staff delete response should indicate no content (1ms)
✓Delete response status code should be NoContent (0ms)
Diagrams
This scenario:Payloads
Retrieving An Existing Staff Member Should Return The Member 51ms🔗
Steps
✓GIVEN A staff member exists (5ms)
✓A valid staff member request (0ms)
✓The staff member is submitted (2ms)
✓The setup response should be created (0ms)
✓Post steps response message status code should be Created (0ms)
✓Response content is valid json should be true (0ms)
✓WHEN The staff member is retrieved by id (21ms)
✓THEN The staff get response should contain the member (22ms)
✓The get response http status should be ok (6ms)
✓Get steps response message status code should be OK (0ms)
✓The get response should be valid json (5ms)
✓Response content is valid json should be true (0ms)
✓The retrieved member should match the created member (3ms)
✓Get steps response id should be '3' (0ms)
✓Get steps response name should be 'Chef-5a1c9e7e9d5847ddbce1a01381833a39' (0ms)
✓Get steps response role should be "Chef" (0ms)
Diagrams
This scenario:Payloads
Toppings Deletion Feature
/toppings - Deleting toppings from the system
Deleting An Existing Topping Should Return No Content Happy Path 24ms🔗
Steps
✓GIVEN A known topping exists (1ms)
✓WHEN The topping is deleted (15ms)
✓THEN The delete response should indicate success (1ms)
✓Delete steps response message status code should be NoContent (0ms)
Diagrams
This scenario:Payloads
Deleting A Non Existent Topping Should Return Not Found 6ms🔗
Steps
✓GIVEN A topping id that does not exist (0ms)
✓WHEN The topping is deleted (1ms)
✓THEN The delete response should indicate not found (1ms)
✓Delete steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Toppings Feature Flag Feature
/toppings - Topping availability controlled by feature flags
Toppings Should Exclude Raspberries When Feature Flag Is Disabled 225ms🔗
Steps
✓GIVEN The raspberry topping feature flag is disabled (163ms)
✓WHEN Toppings are requested (40ms)
✓THEN The toppings response should not include raspberries (14ms)
✓The toppings response http status should be ok (0ms)
✓Toppings steps response message status code should be OK (0ms)
✓The toppings list should be valid json (0ms)
✓Response content is valid json should be true (0ms)
✓The toppings list should not contain raspberries (5ms)
✓Toppings steps response should not contain [ t => t.Name == ToppingDefaults.Raspberries ] (0ms)
Diagrams
This scenario:Payloads
Toppings Should Include Raspberries When Feature Flag Is Enabled 181ms🔗
Steps
✓GIVEN The raspberry topping feature flag is enabled (123ms)
✓WHEN Toppings are requested (29ms)
✓THEN The toppings response should include raspberries (24ms)
✓The toppings response http status should be ok (1ms)
✓Toppings steps response message status code should be OK (0ms)
✓The toppings list should be valid json (2ms)
✓Response content is valid json should be true (0ms)
✓The toppings list should contain raspberries (6ms)
✓Toppings steps response should contain [ t => t.Name == ToppingDefaults.Raspberries ] (0ms)
Diagrams
This scenario:Payloads
Toppings Management Feature
/toppings - Listing available toppings and adding custom toppings
The Toppings Endpoint Should Return All Available Toppings Happy Path 33ms🔗
Steps
✓WHEN The available toppings are requested (10ms)
✓THEN The toppings response should contain the default toppings (21ms)
Diagrams
This scenario:Payloads
Adding A New Topping Should Return The Created Topping 35ms🔗
Steps
✓GIVEN A valid topping request (1ms)
✓WHEN The new topping is submitted (16ms)
✓THEN The topping response should contain the created topping (15ms)
✓The topping post response http status should be created (2ms)
✓Post steps response message status code should be Created (0ms)
✓The topping post response should be valid json (3ms)
✓Response content is valid json should be true (0ms)
✓The created topping should have the correct name (1ms)
✓Post steps response name should be Strawberries (0ms)
✓The created topping should have the correct category (1ms)
✓Post steps response category should be FruitCategory (0ms)
Diagrams
This scenario:Payloads
Toppings Update Feature
/toppings - Updating existing toppings
Updating An Existing Topping Should Return The Updated Topping Happy Path 42ms🔗
Steps
✓GIVEN A known topping exists (0ms)
✓AND A valid update topping request (2ms)
✓WHEN The topping is updated (12ms)
✓THEN The update response should contain the updated topping (18ms)
Diagrams
This scenario:Payloads
Update toppings endpoint is called with invalid or dangerous input 1/1 passed 94ms ยท 63ms warm-up🔗
#Input ParametersStatusDuration
InputsOutputs
1
FieldName
Valuenull
ReasonCategory is required
ErrorMessageName contains potentially dangerous content
ResponseStatusBad Request
Passed94ms
Steps
✓GIVEN A known topping exists (1ms)
✓AND Valid update topping requests with an invalid field InvalidFieldFromRequest { Field = Name, Value = <script>alert('xss')</script>, Reason = Script tag in name }, InvalidFieldFromRequest { Field = Name, Value = <img src=x onerror=alert(1)>, Reason = Event handler in name }, InvalidFieldFromRequest { Field = Category, Value = <script>alert('xss')</script>, Reason = Script tag in category }, InvalidFieldFromRequest { Field = Category, Value = javascript:alert(1), Reason = Javascript protocol }, InvalidFieldFromRequest { Field = Name, Value = , Reason = Name is required }, InvalidFieldFromRequest { Field = Category, Value = , Reason = Category is required } (6ms)
✓WHEN The invalid update topping requests are submitted (76ms)
✓THEN The update responses should each contain the validation error for the invalid field VerifiableErrorResult { ErrorMessage = Name contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Name contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Category contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Category contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Name' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Category' is required., ResponseStatus = Bad Request } (3ms)
Diagrams
This scenario:Payloads
Updating A Non Existent Topping Should Return Not Found 8ms🔗
Steps
✓GIVEN A topping id that does not exist (0ms)
✓AND A valid update topping request (0ms)
✓WHEN The topping is updated (1ms)
✓THEN The update response should indicate not found (1ms)
✓Put steps response message status code should be NotFound (0ms)
Diagrams
This scenario:Payloads
Toppings Xss Validation Feature
/toppings - XSS and input validation for toppings
Toppings endpoint is called with invalid or dangerous input 1/1 passed 120ms🔗
#Input ParametersStatusDuration
InputsOutputs
1
FieldName
Valuenull
ReasonCategory is required
ErrorMessageName contains potentially dangerous content
ResponseStatusBad Request
Passed120ms
Steps
✓GIVEN Valid topping requests with an invalid field InvalidFieldFromRequest { Field = Name, Value = <script>alert('xss')</script>, Reason = Script tag in name }, InvalidFieldFromRequest { Field = Name, Value = <img src=x onerror=alert(1)>, Reason = Event handler in name }, InvalidFieldFromRequest { Field = Category, Value = <script>alert('xss')</script>, Reason = Script tag in category }, InvalidFieldFromRequest { Field = Category, Value = javascript:alert(1), Reason = Javascript protocol }, InvalidFieldFromRequest { Field = Name, Value = , Reason = Name is required }, InvalidFieldFromRequest { Field = Category, Value = , Reason = Category is required } (18ms)
✓WHEN The invalid topping requests are submitted (62ms)
✓THEN The responses should each contain the validation error for the invalid field VerifiableErrorResult { ErrorMessage = Name contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Name contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Category contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Category contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Name' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Category' is required., ResponseStatus = Bad Request } (3ms)
Diagrams
This scenario:Payloads
Waffles Content Negotiation Feature
/waffles - Content negotiation and unsupported media types
Sending a request with an unsupported content type should return an unsupported media type response 3/3 passed 19ms🔗
#Input ParametersStatusDuration
Content Type
1application/xmlPassed3ms
2text/htmlPassed9ms
3text/plainPassed6ms
Steps
✓GIVEN A waffle request with content type application/xml (0ms)
✓WHEN The waffles are prepared (0ms)
✓THEN The response should indicate unsupported media type (0ms)
✓Response status code should be UnsupportedMediaType (0ms)
Diagrams
This scenario:Payloads
Waffles Creation Feature
/waffles - Creating waffles with ingredients and optional toppings
A Valid Waffle Request Should Return A Fresh Batch Happy Path 73ms🔗
Steps
✓GIVEN A valid waffle recipe with all ingredients (18ms)
✓WHEN The waffles are prepared (22ms)
✓THEN The waffles response should contain a valid batch with all ingredients (25ms)
✓AND The cow service should have received a milk request (3ms)
✓Requests should contain [ r => r.RequestUri.AbsolutePath == "/milk" && r.Method == HttpMethod.Get ] (0ms)
Diagrams
This scenario:Payloads
A Waffle Request With More Toppings Than Allowed Should Return A Bad Request Response 127ms🔗
Steps
✓GIVEN The max toppings per item is 5 (17ms)
✓AND A valid waffle recipe with all ingredients (48ms)
✓AND The request has more toppings than the configured limit (1ms)
✓WHEN The waffles are prepared (46ms)
✓THEN The waffles response should indicate too many toppings (7ms)
✓The response http status should be bad request (1ms)
✓Waffle steps response message status code should be BadRequest (0ms)
✓The response should contain max toppings error (2ms)
✓Waffle error response body should contain MaxToppingsExceeded (0ms)
Diagrams
This scenario:Payloads
Waffles endpoint is called with invalid ingredients should return a bad request response 1/1 passed 21ms🔗
#Input ParametersStatusDuration
InputsOutputs
1
FieldMilk
Value<img onerror=x>
ReasonXSS in butter
ErrorMessage'Milk' is required
ResponseStatusBad Request
Passed21ms
Steps
✓GIVEN Valid waffle requests with an invalid field InvalidFieldFromRequest { Field = Milk, Value = , Reason = Milk is required }, InvalidFieldFromRequest { Field = Flour, Value = , Reason = Flour is required }, InvalidFieldFromRequest { Field = Eggs, Value = , Reason = Eggs is required }, InvalidFieldFromRequest { Field = Butter, Value = , Reason = Butter is required }, InvalidFieldFromRequest { Field = Milk, Value = <script>alert</script>, Reason = XSS in milk }, InvalidFieldFromRequest { Field = Butter, Value = <img onerror=x>, Reason = XSS in butter } (2ms)
✓WHEN The invalid waffle requests are submitted (11ms)
✓THEN The responses should each contain the validation error for the invalid field VerifiableErrorResult { ErrorMessage = 'Milk' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Flour' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Eggs' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = 'Butter' is required., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Milk contains potentially dangerous content., ResponseStatus = Bad Request }, VerifiableErrorResult { ErrorMessage = Butter contains potentially dangerous content., ResponseStatus = Bad Request } (2ms)
Diagrams
This scenario:Payloads