Unexpected assertion error with `satisfiesContract()` when impl has more operations than design apiDoc under same path

[atsu85]

Expected behavior

When design api-doc includes less operations from the same path compared to implementation api-doc, then

SwaggerAssertions.assertThat(implApiDoc)
                .satisfiesContract(designApiDoc);

shouldn't fail...

Actual behaviour

...but actually currently the test fails with an error having output similar to following:

org.assertj.core.api.SoftAssertionError: 
The following 2 assertions failed:
1) [Checking 'DELETE' operation of path '/pets/{petId}'] expected:<null> but was:<io.swagger.models.Operation@79d154eb[deletePet]>
at ConsumerDrivenValidator.validateOperation(ConsumerDrivenValidator.java:259) expected:<null> but was:<io.swagger.models.Operation@79d154eb[deletePet]>
2) [Checking 'POST' operation of path '/pets/{petId}'] expected:<null> but was:<io.swagger.models.Operation@53f708e3[updatePetWithForm]>
at ConsumerDrivenValidator.validateOperation(ConsumerDrivenValidator.java:259) expected:<null> but was:<io.swagger.models.Operation@53f708e3[updatePetWithForm]>

    at org.assertj.core.api.SoftAssertions.assertAll(SoftAssertions.java:133)
    at io.github.robwin.swagger.test.ConsumerDrivenValidator.validateSwagger(ConsumerDrivenValidator.java:75)
    at io.github.robwin.swagger.test.SwaggerAssert.satisfiesContract(SwaggerAssert.java:97)
    at io.github.robwin.swagger.test.SwaggerAssert.satisfiesContract(SwaggerAssert.java:109)
    at io.github.robwin.swagger.SwaggerConsumerDrivenAssertTest.shouldntFailWhenImplHasMoreOperationsOfSamePath(SwaggerConsumerDrivenAssertTest.java:149)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
    at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
    at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
    at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
    at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

[RobWin]

Thx for creating an issue.

[atsu85]

@RobWin , could you take a look at the tiny PR that fixes this issue?

[RobWin]

Yes but not today

[atsu85]

ok, i discovered this issue when preparing test & fix for issue #28