Kuadrant / Kuadrant/developer-portal-controller

Add unit tests for name generation, data transformation, and object helpers

Open
#76 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement good first issue triage/accepted
Dominant language
Go
Stars
2
Forks
12
Avg merge
13h 37m
Merged PRs (30d)
5

Description

Summary

Write unit tests for the pure functions that generate deterministic names, transform data between types, and manage object annotations. All testable without envtest.

Testing Guidance

For each function, think about:

  • What does it return for normal, expected input?
  • What happens at the boundaries — empty strings, nil objects, missing fields?
  • If there's branching logic, have you covered each branch?

Scope

internal/controller/devportal_helper.go
  • APIKeyRequestName() — generates a DNS-1123 compliant name from an APIKey using a SHA-256 hash suffix. Think about: does the output meet DNS-1123 rules? Is it deterministic (same input = same output)? Different namespace/name combinations that could collide without the hash.
internal/controller/apikey_secret_controller.go
  • enforcementSecretName() — same pattern as above, generates a deterministic name for enforcement secrets. Same considerations apply.
api/v1alpha1/apikey_types.go
  • APIProductKey() — returns an ObjectKey for the referenced APIProduct, falling back to the APIKey's own namespace if the ref namespace is empty. Test the fallback behaviour.
api/v1alpha1/apikeyrequest_types.go
  • ClientObject() — converts an APIKeyReference to an ObjectKey. Straightforward struct conversion.
api/v1alpha1/apiproduct_types.go
  • PlanPolicyIntoPlans() — converts a PlanPolicy's plan list into PlanSpec slice. Test with nil input, empty plan list, and multiple plans.
internal/controller/apiproduct_controller.go
  • extractIssuerURLFromAuthScheme() — finds the first JWT issuer URL from an auth scheme. Consider: no authentication map, authentication with non-JWT entries, multiple JWT entries (which one wins?), nil auth scheme.
internal/controller/apikeyrequest_controller.go
  • apiKeyRequestSpecMutator() — compares existing vs desired specs, mutates existing if different, returns whether mutation occurred. Test: specs are equal (no mutation), specs differ (mutation happens), verify the existing object is actually updated.
internal/reconcilers/base_reconcilers.go
  • TagObjectToDelete() / IsObjectTaggedToDelete() — adds/checks a deletion annotation. Test: object with no annotations, object with existing annotations, round-trip (tag then check).

Review & Verification

PRs should include:

  • How to review the changes (areas of interest, suggested review order)
  • Steps to confirm locally: make test runs and passes

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the listed functions in internal/controller/devportal_helper.go, internal/controller/apikey_secret_controller.go, the api/v1alpha1 type files, and the reconcilers. Read each function and add unit coverage for normal, boundary, branching, mutation, and round-trip cases described in the issue. Run make test; done means all requested functions are covered and the test suite passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.