add support for grouping requests in scenarios for which order is not important

[jhkuperus]

The current use case we're providing with scenarios only supports linear scenarios. If the app we're testing were to request resources asynchronously, the order of a scenario might no longer match that of the actual requests. This calls for supporting a scenario type asynchronousScenario()

[jhkuperus]

Also, this can be achieved by using sub-scenarios. For example, we could allow something like this:

new Scenario.Builder()
  .sequentialScenario()
  .on('endpoint1')
  .respondWith(...)
  .then()
  .awaitSubScenarios(
    new Scenario.Builder()
      .infiniteLoop()
      .on('endpoint2')
      .respondWith(...)
      .build(),
    new Scenario.Builder()
       .sequentialScenario()
       .on('endpoint3')
       .respondWith(...)
       .then()
       .on('endpoint4')
       .respondWith(...)
       .build()
    )
    .then()
    .on('endpoint5')
    .respondWith(...)
    .build();

This would create a scenario which awaits a call on endpoint1, after which it will launch two sub-scenarios. One of those subscenarios is an infiniteLoop scenario, which keeps returning the same response on endpoint2, while the other awaits a sequence of calls on endpoint3 and endpoint4. When both subscenarios have completed (or run at least once), the outer scenario continues to await a call to endpoint5.

[KrekkieD]

cacheQueue serves from the list of caches the first hit, making the order less specific but still maintains an order by returning (and removing) the first match from the queue

[jhkuperus]

Lekker bezig weer!

Ik voel me nou toch wel beetje schuldig dat ik nog niet echt iets heb bijgedragen sinds maart. Wat JP zei over ‘ik heb nog nooit zoveel geprogrammeerd’ komt bij mij neer op: ik ben nog nooit zo vaak op m’n laptop in slaap gevallen :P

Maar ondertussen heb ik wel de nieuwe scenario-engine uitgewerkt. Nu moet ik hem alleen nog even intypen.

—JH

On 20 May 2015, at 21:37, KrekkieD [email protected] wrote:

cacheQueue serves from the list of caches the first hit, making the order less specific but still maintains an order by returning (and removing) the first match from the queue

—
Reply to this email directly or view it on GitHub #23 (comment).

[KrekkieD]

Haha ja kan me voorstellen dat het zijn tol vraagt. Mijn zusje heeft ook een kotertje sinds een week of 4 nu, die leven ook wat ‘anders’ op het moment ;)

De CacheQueue plugin is misschien nuttig om even naar te kijken. Dat is een repository die je kan voeden met een array van caches, array volgorde is dan more or less de volgorde waarin ze terug geserveerd worden.

Verschil met de scenario repository is dat de cacheQueue de first requestKey hit terug geeft, en wel de mogelijkheid biedt om meerdere responses voor eenzelfde requestKey te leveren. Omdat het een array is en niet een object met requestKey: cacheEntry heb je geen issues met overwrites van de cacheEntry door dubbele keys.

Op deze manier kunnen we bij MyA alle endpoints recorden, CMS inclusief, en de volgorde waarin requests binnen komen maakt dan niet zoveel uit, zolang je niet per ongeluk een hele andere richting inslaat in je E2E.

Over het algemeen houdt het in dat je een cacheQueue vult met zo’n 20 caches, en de volgorde is dan iets ala:
1, 2, 3, 5, 4, 6, 8, 7, .. etc. Dus kleine volgordelijke verschillen, waardoor dingen als overlappende Ajax calls niet je scenario om zeep helpen (denk bijv aan een shared email check die een aantal backend calls lijkt te doen, en dat halverwege die call toch het form wordt gesubmit met weer eigen backend calls, waarbij normaliter de requestvolgorde niet te voorspellen is). Tot nu toe slikt dit alles :) En mooiste is misschien nog wel dat de caches gewoon in een json file zitten (want simpele array zonder functions), en we die dus naast de E2E test kunnen neerzetten en kunnen insturen naar de http-api als eerste it() van de describe. Best nice! :)

Recording werkt door gewoon record op true te zetten (de settings voor considerRecording was ik nog mee bezig), en als je dan klaar bent met recorden moet je zelf de http-api GET url openen in de browser om de array te zien. Die kan je dan gewoon copy/pasten naar een file, dus geen sjieke GUI voor nog, en geen write to file. Haalt wel een hoop hassle weg.

Daarnaast heb ik een cacheConglomerate plugin neergezet, die een soort vergelijkbaar is met de normale memory-repository. Ik weet ff niet meer waarom ik hem gemaakt had, er was toen een bepaalde use-case voor volgens mij die niet direct kon met de memory-repository.

Ben je wel alweer aan het werk bij de Rabo? Alles flap daar?

Grts!

-- 
Gregory Cowan | Amnzero
Sent with Airmail

On 21 May 2015 at 07:50:38, Jan-Hendrik Kuperus ([email protected]) wrote:

Lekker bezig weer!

Ik voel me nou toch wel beetje schuldig dat ik nog niet echt iets heb bijgedragen sinds maart. Wat JP zei over ‘ik heb nog nooit zoveel geprogrammeerd’ komt bij mij neer op: ik ben nog nooit zo vaak op m’n laptop in slaap gevallen :P

Maar ondertussen heb ik wel de nieuwe scenario-engine uitgewerkt. Nu moet ik hem alleen nog even intypen.

—JH

On 20 May 2015, at 21:37, KrekkieD [email protected] wrote:

cacheQueue serves from the list of caches the first hit, making the order less specific but still maintains an order by returning (and removing) the first match from the queue

—
Reply to this email directly or view it on GitHub #23 (comment).

—
Reply to this email directly or view it on GitHub.

[jhkuperus]

Ik zal eerst de develop branch eens gaan bestuderen :) Ondertussen zijn hier ook al meer geluiden om over te stappen op een ander stub-ding. Er zijn diversen die al zoiets hebben van ‘dat nodejs tooltje van jou, is dat een beetje makkelijk te gebruiken?’ :)

Ik ben uiteindelijk maar 1 dag weggeweest bij de Rabo. Wel die eerste week wat kortere dagen gemaakt, maar niet helemaal vrij genomen. (Blijf ZZP’er natuurlijk)
Er zijn hier een hoop uitdagingen, maar gelukkig ook wel de wil om dingen te veranderen. We zijn nu al langzaam maar zeker alle SOAP crap aan het ombouwen naar REST.

Laten we het zo zeggen: het team en de reisafstand maken een hoop goed ;)

Zal ik ff een datumprikker maken voor onze date?

—JH

On 21 May 2015, at 09:20, KrekkieD [email protected] wrote:

Haha ja kan me voorstellen dat het zijn tol vraagt. Mijn zusje heeft ook een kotertje sinds een week of 4 nu, die leven ook wat ‘anders’ op het moment ;)

De CacheQueue plugin is misschien nuttig om even naar te kijken. Dat is een repository die je kan voeden met een array van caches, array volgorde is dan more or less de volgorde waarin ze terug geserveerd worden.

Verschil met de scenario repository is dat de cacheQueue de first requestKey hit terug geeft, en wel de mogelijkheid biedt om meerdere responses voor eenzelfde requestKey te leveren. Omdat het een array is en niet een object met requestKey: cacheEntry heb je geen issues met overwrites van de cacheEntry door dubbele keys.

Op deze manier kunnen we bij MyA alle endpoints recorden, CMS inclusief, en de volgorde waarin requests binnen komen maakt dan niet zoveel uit, zolang je niet per ongeluk een hele andere richting inslaat in je E2E.

Over het algemeen houdt het in dat je een cacheQueue vult met zo’n 20 caches, en de volgorde is dan iets ala:
1, 2, 3, 5, 4, 6, 8, 7, .. etc. Dus kleine volgordelijke verschillen, waardoor dingen als overlappende Ajax calls niet je scenario om zeep helpen (denk bijv aan een shared email check die een aantal backend calls lijkt te doen, en dat halverwege die call toch het form wordt gesubmit met weer eigen backend calls, waarbij normaliter de requestvolgorde niet te voorspellen is). Tot nu toe slikt dit alles :) En mooiste is misschien nog wel dat de caches gewoon in een json file zitten (want simpele array zonder functions), en we die dus naast de E2E test kunnen neerzetten en kunnen insturen naar de http-api als eerste it() van de describe. Best nice! :)

Recording werkt door gewoon record op true te zetten (de settings voor considerRecording was ik nog mee bezig), en als je dan klaar bent met recorden moet je zelf de http-api GET url openen in de browser om de array te zien. Die kan je dan gewoon copy/pasten naar een file, dus geen sjieke GUI voor nog, en geen write to file. Haalt wel een hoop hassle weg.

Daarnaast heb ik een cacheConglomerate plugin neergezet, die een soort vergelijkbaar is met de normale memory-repository. Ik weet ff niet meer waarom ik hem gemaakt had, er was toen een bepaalde use-case voor volgens mij die niet direct kon met de memory-repository.

Ben je wel alweer aan het werk bij de Rabo? Alles flap daar?

Grts!

Gregory Cowan | Amnzero
Sent with Airmail

On 21 May 2015 at 07:50:38, Jan-Hendrik Kuperus ([email protected]) wrote:

Lekker bezig weer!

Ik voel me nou toch wel beetje schuldig dat ik nog niet echt iets heb bijgedragen sinds maart. Wat JP zei over ‘ik heb nog nooit zoveel geprogrammeerd’ komt bij mij neer op: ik ben nog nooit zo vaak op m’n laptop in slaap gevallen :P

Maar ondertussen heb ik wel de nieuwe scenario-engine uitgewerkt. Nu moet ik hem alleen nog even intypen.

—JH

On 20 May 2015, at 21:37, KrekkieD [email protected] wrote:

cacheQueue serves from the list of caches the first hit, making the order less specific but still maintains an order by returning (and removing) the first match from the queue

—
Reply to this email directly or view it on GitHub #23 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub #23 (comment).