Currently we only test the creation of new infrastructure based on k8s resources - e.g. Ingress, RouteGroup etc - but we don't test update actions, when we already have infrastructure created and something changes in k8s cluster resulting in a update of the infrastructure.
For example: For some specific reason we need that a RouteGroup don't share an LB anymore and previously it shared an LB with an existing ingress. In the case the ingress-controller will use the update function to change the existing stack and also will create a new stack for RouteGroup LB.
What is the goal of the topic? (optional)
Improve test coverage in kube-aws-ingress-controller.
Impact
With better coverage we will increase our confidence in changes to the component and also will improve the understanding of the code base.
To accomplish the goal of this task we need to create logic to store history of changes so we can compare with a Golden file the same way we do with Golden file tests for stack creation.
With this new logic in the mock we will be able to create tests around stack updates too.
Problem
Currently we only test the creation of new infrastructure based on k8s resources - e.g. Ingress, RouteGroup etc - but we don't test update actions, when we already have infrastructure created and something changes in k8s cluster resulting in a update of the infrastructure.
For example: For some specific reason we need that a RouteGroup don't share an LB anymore and previously it shared an LB with an existing ingress. In the case the ingress-controller will use the update function to change the existing stack and also will create a new stack for RouteGroup LB.
What is the goal of the topic? (optional)
Improve test coverage in
kube-aws-ingress-controller.Impact
With better coverage we will increase our confidence in changes to the component and also will improve the understanding of the code base.
Solution
What needs to be changed?
In
./aws/fake/cf.goin theUpdateStackmock we should not use the same variables to store history of changes asCreateStackbecause this can create bugs.To accomplish the goal of this task we need to create logic to store history of changes so we can compare with a Golden file the same way we do with Golden file tests for stack creation.
With this new logic in the mock we will be able to create tests around stack updates too.
Acceptance criteria
UpdateStackmock does not use the same logic as CreateStack mock