aws-cloudformation / aws-cloudformation/cloudformation-cli-java-plugin
[Proposal] Enable Lombok.toBuilder annotation flag in ResourceModel template
- Lingua principale
- Java
- Stelle
- 30
- Fork
- 48
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Descrizione
Dear team,
I wonder if you folks would have any concerns about enabling `toBuilder` attribute for Lombok @Builder by default or with an additional schema flag?
At the moment, `ResourceModel` template generates non-parametrized @Builder: https://github.com/aws-cloudformation/cloudformation-cli-java-plugin/blob/master/python/rpdk/java/templates/init/guided_aws/ResourceModel.java#L20
One of the reasons I would like to see this flag enabled is a significant simplification of overriding massive resource model definitions in testing, especially in testing an `UpdateHandler`.
Here is an example:
```java
public class AbstractTestBase {
protected static final ResourceModel MODEL_BEFORE;
protected static final ResourceModel MODEL_AFTER;
static {
MODEL_BEFORE = ResourceModel.builder()
.foo("foo-before")
.bar("bar-before")
.baz("baz-before")
.build();
MODEL_AFTER = ResourceModel.builder()
.foo("foo-before")
.bar("bar-before")
.baz("totally-different-baz")
.build();
}
}
```
Assume I'm using these models in `UpdateHandler` test suite. If the update flow has a broad branching based on model attribute invariants, one has to initiate separate model instances for each branch case. It's completely fine for a 5-10 attribute models, but the burden of carrying things around grows once one has to deal with a 30-50 attribute model.
Having `toBuilder = true` enabled in `ResourceModel` definition would let one define models like
```java
public class AbstractTestBase {
protected static final ResourceModel MODEL_BEFORE;
protected static final ResourceModel MODEL_AFTER;
static {
MODEL_BEFORE = ResourceModel.builder()
.foo("foo-before")
.bar("bar-before")
.baz("baz-before")
.build();
MODEL_AFTER = MODEL_BEFORE.toBuilder()
.baz("totally-different-baz")
.build();
}
}
```
In fact, being able to override a static model locally within the current test case scope is even better, it could look like:
```java
public class UpdateHandlerTest extends AbstractTestBase {
//...
public void handleRequest_SimpleSuccess() {
final ResourceModel modelWithUpdatedBaz = MODEL_BEFORE.toBuilder()
.baz("totally-different-baz")
.build();
//...
}
}
```
Guida per i contributori
Apri la guida per i contributori
Valutazione
Questa issue non è ancora stata valutata.