helm-unittest / helm-unittest

BDD styled unit test framework for Kubernetes Helm charts as a Helm plugin.
MIT License
801 stars 254 forks source link

Compare two different paths #405

Open dragonpil opened 2 weeks ago

dragonpil commented 2 weeks ago

We know that we could set parameters or value files and inject so the rendering to get a known value rendered at a known path. But for some use cases we are not interested in the implementation but just in the result. We want to verify conditions between different paths (in a second iteration maybe between different Documents). For example we want to verify that for every Deployment a corresponding Service is defined

kind: Service
apiVersion: v1
metadata:
  name: reference
spec:
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  selector:
    app: reference
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: 'reference'
spec:
  selector:
    matchLabels:
      app: 'reference'
  template:
    metadata:
      labels:
        app: 'reference'
    spec:
      containers:
        - name: 'main-1'
          image: '{{ .Values.deployment.dockerImageName }}:{{ .Chart.Version }}'
          imagePullPolicy: Always
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: 'openshift'
          ports:
            - containerPort: 8080

we like to compare here the app: reference from service and deployment is the same. We dont like to inject it via value because thats in implementation detail we don't know and do not like to enforce.

Is there already a way to test that?

ivankatliarchuk commented 1 week ago

Hi. I'm trying to understand your proposal. Would you be able to share some examples that you have in mind? Am I understanding you correctly, we filter resources using labels or other selection mehods?

dragonpil commented 1 week ago

In the above example the service has a selector for label app == reference. In the deployment you have the corresponding label app == references defined. Actually we could implement both with the same parameter and then write two test cases to test if the path in service equals the injected parameter and if the path in the Deployment equals the injected parameter.

What we like to have is an exist and equals with two different paths. So that we could say directly path1 == path2. I think we also would need two different documents selectors so that we could define for documents with kind deployment and path spec.metadata.labels.app there exist a document with kind service and path spec.selector.app. And as a second test both these paths are equal in value, so reference in this example without the need that we use here a parameter, value.

quintush commented 3 days ago

Hello @dragonpil, @ivankatliarchuk

Although this issue is more like a new feature it could be resolved with the solution similar to suggenstions I made for #289, #345 (still working on a separate issue with more details what needs to be done and validated).

The way I see it, it would work like this: As in your example the documents and paths are different you would need a more complex jsonPath expression to identify the different results as a single array and you still need to have to set the value set as a static value (from perspective of a unittest/whiteboxtest approach it would still have my preference).

Let me know if you have any suggestions/improvments.

Greetings, @quintush