Investigate why State is not working

[bartoszmajsak]

Hoverfly has a concept of State which can be used to simulate stateful behaviour of the service. Let's consider simple example:

• calling DELETE for given resource for the first time will result with 204
• calling it the second time should result in 404 (perhaps?)

The problem is that Hoverfly will by default always match against first request/response pair. In order to we should use state transitions. It seems that this is not working as documented in Hoverfly.

The idea here is to fix this test.

If the State approach won't work is there any other way we can mimic this behaviour?

[bartoszmajsak]

I added an isolated test to ease the work and separated simulation file with state transitions as I tried it.

You can grab it from my branch.

The idea would be to

• Figure out if the state transition works in hoverfly and can be used for such a scenario (is it my misuse or something odd in Hoverfly?)
  • might be worth to reach out to Hoverfly folks if we are stuck on that
• If solvable remove the isolated test and adjust original simulation file

[MatousJobanek]

I've been trying to figure out what is going on there and I got slightly confused by the intention of the test - I've been using the GitHubServiceHoverflyStateIT from the Bartosz fork. I have two questions:

1. the test is an in-container test and is using Hoverfly as a @ClassRule. But the fix introduced in latest Arquillian-core version disables invoking class rules inside of the container - they are invoked only on the client side, but the test is invoked inside of the container. Is this expected?

2. the expected message of the failure is "Could not create webhook as it already exists" (which equals to POST call I guess) but inside of the simulation file is the transition state set for deletion. Is this an intention?

[bartoszmajsak]

the test is an in-container test and is using Hoverfly as a @ClassRule. But the fix introduced in latest Arquillian-core version disables invoking class rules inside of the container - they are invoked only on the client side, but the test is invoked inside of the container. Is this expected?

It works all on the same host so we only need to set hoverfly proxy once. As latest changes in Arquillian solved the problem of firing @ClasRules twice (both as-client and in-container) and only fire on the client side we are good. Hoverfly as such is not really needed to be fired from the container as in this case we won't consider remote containers to run our tests against. Of course this approach is not perfect and not portable, but that's the best we can now.

the expected message of the failure is "Could not create webhook as it already exists" (which equals to POST call I guess) but inside of the simulation file is the transition state set for deletion. Is this an intention?

Ah, sorry - my bad. The use case is the same, but I messed up simulation file. It needs to be POST with a different error.

[MatousJobanek]

The problem is in the hoverfly-java project - there is missing support for the latest version of the simulation config. issue: https://github.com/SpectoLabs/hoverfly-java/issues/152 PR: https://github.com/SpectoLabs/hoverfly-java/pull/153

[bartoszmajsak]

@MatousJobanek can you ping hoverfly folks about the release?

[MatousJobanek]

Done: https://github.com/SpectoLabs/hoverfly-java/pull/153#issuecomment-366619459