Использование Java для создания PACT Я не могу установить минимальное значение numberType в теле
Я изучаю, как использовать PACT в своем проекте Java, и я хотел бы определить ограничения некоторых значений ожидаемого результата. Например, в один запрос /hello-world Я ожидаю получить число в атрибуте id, которое всегда должно быть больше нуля.
package com.thiagomata.pact.hello.consumer.consumer;
import au.com.dius.pact.consumer.ConsumerPactBuilder;
import au.com.dius.pact.consumer.PactVerificationResult;
import static io.pactfoundation.consumer.dsl.LambdaDsl.newJsonBody;
import au.com.dius.pact.consumer.dsl.PactDslJsonBody;
import au.com.dius.pact.model.MockProviderConfig;
import au.com.dius.pact.model.RequestResponsePact;
import com.thiagomata.pact.hello.consumer.models.Greeting;
import io.pactfoundation.consumer.dsl.LambdaDslJsonBody;
import org.junit.Assert;
import org.junit.Test;
import scala.tools.jline_embedded.internal.Log;
import static au.com.dius.pact.consumer.ConsumerPactRunnerKt.runConsumerTest;
import static org.junit.Assert.assertEquals;
public class NameApplicationPactTest {
@Test
public void testNamePact() throws Throwable {
Log.debug("inside the test");
/**
* Creating the mock server
*
* Define the expected input
* Using relative address
* The provider address will be automatically created
* The provider port will be automatically created
* Define the expected output
* Keep the id as a undefined integer
* Set the content to the test
*/
RequestResponsePact pact = ConsumerPactBuilder
.consumer("hello_world_consumer")
.hasPactWith("hello_world_provider")
.uponReceiving("a request of hello world")
.path("/hello-world")
.matchQuery("name","johny")
.method("GET")
.willRespondWith()
.body(
newJsonBody( (LambdaDslJsonBody o) -> o.
numberType("id"). // <====================================
stringType("content", "Hello johny")
).build()
)
.toPact();
/**
* Let the Pact define the mock server address and port
*/
MockProviderConfig config = MockProviderConfig.createDefault();
/**
* Create the mock server into the defined config and with the
* pact result prepared
*/
PactVerificationResult result = runConsumerTest(
pact,
config,
mockServer -> {
Log.debug("inside mock server");
/**
* Pass the mock server configuration to the consumer classes
*/
DummyConsumer consumer = new DummyConsumer(
mockServer.getUrl(),
mockServer.getPort(),
"johny"
);
/**
* Now, when the code internally fires to the
* mockServer we should get the expected answer
*/
Greeting greeting = consumer.getGreeting();
Log.debug(greeting);
Assert.assertNotNull(
"Greeting id should not be null",
greeting.getId()
);
/**
* Currently I am not able to define a rule into the
* DSL Matching methods to assure that the value should
* be bigger than 0
*/
Assert.assertTrue( greeting.getId() > 0 ); // <=================================================
assertEquals(
"Validate expected default greeting content",
"Hello johny",
greeting.getContent()
);
Log.debug("status code = " + consumer.getStatusCode() );
Assert.assertTrue(
"test consumer status code",
consumer.getStatusCode().equals(
200
)
);
}
);
/**
* If some Assert inside of the anonymous functions fails
* it will not automatically throw a failure.
*
* We need to capture the error from the result
*/
if (result instanceof PactVerificationResult.Error) {
throw ((PactVerificationResult.Error) result).getError();
}
assertEquals(PactVerificationResult.Ok.INSTANCE, result);
}
}
Кто-то может сказать, что в PACT он не способен применять такие ограничения. Но, глядя на сгенерированный PACT, похоже, что создание минимального и максимального значений для генераторов должно быть возможным в PACT:
{
"provider": {
"name": "hello_world_provider"
},
"consumer": {
"name": "hello_world_consumer"
},
"interactions": [
{
"description": "Test User Service",
"request": {
"method": "GET",
"path": "/hello-world"
},
"response": {
"status": 200,
"headers": {
"content-type": "application/json",
"Content-Type": "application/json; charset\u003dUTF-8"
},
"body": {
"id": 100,
"content": "string"
},
"matchingRules": {
"body": {
"$.id": {
"matchers": [
{
"match": "integer"
}
],
"combine": "AND"
},
"$.content": {
"matchers": [
{
"match": "type"
}
],
"combine": "AND"
}
}
},
"generators": {
"body": {
"$.id": {
"type": "RandomInt",
"min": 0, /* <======================================== */
"max": 2147483647
},
"$.content": {
"type": "RandomString",
"size": 20
}
}
}
},
"providerStates": [
{
"name": "default"
}
]
}
],
"metadata": {
"pact-specification": {
"version": "3.0.0"
},
"pact-jvm": {
"version": "3.5.10"
}
}
}
Я пытаюсь найти способ сделать это, глядя на код PACT. Итак, следуя дорожке numberType метод, из LambdaDsl:
/* ... */
public LambdaDslObject numberType(final String... names) {
object.numberType(names);
return this;
}
/* ... */
Этот метод вызывает object.numberTypes что это в LambdaDslJsonBody с помощью этих возможных методов:
/**
* Attribute that can be any number
* @param name attribute name
*/
public PactDslJsonBody numberType(String name) {
generators.addGenerator(
Category.BODY,
matcherKey(name),
new RandomIntGenerator(0, Integer.MAX_VALUE) // <========================
);
return numberType(name, 100);
}
/**
* Attributes that can be any number
* @param names attribute names
*/
public PactDslJsonBody numberType(String... names) {
for (String name: names) {
numberType(name);
}
return this;
}
/**
* Attribute that can be any number
* @param name attribute name
* @param number example number to use for generated bodies
*/
public PactDslJsonBody numberType(String name, Number number) {
body.put(name, number);
matchers.addRule(matcherKey(name), new NumberTypeMatcher(NumberTypeMatcher.NumberType.NUMBER));
return this;
}
Там, где есть только один генератор, он всегда начинается с нуля.
Итак, есть какой-то возможный способ создания такого рода генератора случайных чисел в PACT, который гарантирует, что значение сгенерированного случайного числа будет больше нуля или меньше 100?
1 ответ
Это выполнимо (заменив генератор значений по умолчанию), но требует применения небольшого обходного пути. Вы можете добавить собственный генератор в список генераторов, возвращаемый DslPart.getGenerators() метод, что-то вроде:
DslPart.getGenerators()
.addGenerator(Category.BODY, ".id", new RandomIntGenerator(0, 100));
Это переопределит генератор для $.id поле, созданное при вызове .numberType("id") метод. Взгляните на этот примерный тест потребительского контракта:
import au.com.dius.pact.consumer.Pact;
import au.com.dius.pact.consumer.PactProviderRuleMk2;
import au.com.dius.pact.consumer.PactVerification;
import au.com.dius.pact.consumer.dsl.DslPart;
import au.com.dius.pact.consumer.dsl.PactDslJsonBody;
import au.com.dius.pact.consumer.dsl.PactDslWithProvider;
import au.com.dius.pact.model.RequestResponsePact;
import au.com.dius.pact.model.generators.Category;
import au.com.dius.pact.model.generators.RandomIntGenerator;
import org.codehaus.jackson.map.ObjectMapper;
import org.junit.Rule;
import org.junit.Test;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import java.util.HashMap;
import java.util.Map;
import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.MatcherAssert.assertThat;
public class PactIntGeneratorTest {
@Rule
public PactProviderRuleMk2 mockProvider = new PactProviderRuleMk2("providerA", "localhost", 8080, this);
@Pact(consumer = "consumerA", provider = "providerA")
public RequestResponsePact requestA(PactDslWithProvider builder) throws Exception {
final DslPart body = new PactDslJsonBody()
.numberType("id")
.stringType("content", "Hello johny");
body.getGenerators()
.addGenerator(Category.BODY, ".id", new RandomIntGenerator(0, 100));
return builder
.uponReceiving("(GET) /foo")
.path("/foo")
.method("GET")
.willRespondWith()
.status(200)
.body(body)
.toPact();
}
@Test
@PactVerification(fragment = "requestA")
public void testRequestA() throws IOException, InterruptedException {
//given:
final ObjectMapper objectMapper = new ObjectMapper();
//when:
final InputStream json = new URL("http://localhost:8080/foo").openConnection().getInputStream();
final Map response = objectMapper.readValue(json, HashMap.class);
//then:
assertThat(((Integer) response.get("id")) > 0, is(true));
//and:
assertThat(response.get("content"), is(equalTo("Hello johny")));
}
}
Это не точно ваш случай, но он показывает, как переопределить генератор для $.id поле. После выполнения этого теста генерируется следующий файл Pact:
{
"provider": {
"name": "providerA"
},
"consumer": {
"name": "consumerA"
},
"interactions": [
{
"description": "(GET) /foo",
"request": {
"method": "GET",
"path": "/foo"
},
"response": {
"status": 200,
"headers": {
"Content-Type": "application/json; charset=UTF-8"
},
"body": {
"id": 100,
"content": "Hello johny"
},
"matchingRules": {
"body": {
"$.id": {
"matchers": [
{
"match": "number"
}
],
"combine": "AND"
},
"$.content": {
"matchers": [
{
"match": "type"
}
],
"combine": "AND"
}
}
},
"generators": {
"body": {
"$.id": {
"type": "RandomInt",
"min": 0,
"max": 100
}
}
}
}
}
],
"metadata": {
"pact-specification": {
"version": "3.0.0"
},
"pact-jvm": {
"version": "3.5.10"
}
}
}
Как вы видете RandomIntGenerator используется с атрибутами min:0 а также max:100,
Последнее, на что стоит обратить внимание: разница между контрактными и функциональными тестами
Помните, что генераторы используются только для генерации значений, которые передаются поставщику, когда выполняется тест проверки контракта поставщика. Пользовательский генератор, который я создал, не изменяет контракт - он не говорит, что только значения от 0 до 100 являются правильными. Он будет генерировать значение в этом диапазоне только тогда, когда провайдер выполняет проверку контракта. Таким образом, ваш контракт все еще действителен для id как 1001 или 12700 и т. д. И это нормально, потому что контрактные тесты не являются функциональными тестами. Потребители не должны навязывать такие бизнес-правила. В противном случае вы могли бы быстро столкнуться с ситуацией, когда consumerA Говорит, что id правильно, когда это между 0 и 100, в то время как consumerB Говорит, что id Это верно только в том случае, если между 99 и 999. Я знаю, что заманчиво создавать очень конкретные контракты, но это прямой путь к чрезмерной спецификации, которая удерживает поставщика от разработки. Надеюсь, поможет.