Create fake data for rest mapper running in Kubernetes
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
If you need fake data for a Kubernetes RESTMapper, you usually do not want fake Pods or fake Deployments first. What the mapper actually needs is fake API mapping information: group, version, kind, resource name, and whether the resource is namespaced.
What RESTMapper Really Maps
In client-go, a RESTMapper translates between concepts such as:
- '
Podas a kind' - '
podsas a resource' - '
v1as a version' - namespace scope versus cluster scope
That means testing code that uses a mapper is often simpler than people expect. You do not need a live cluster just to answer questions like "what resource corresponds to this kind?"
A Simple Fake Mapper with DefaultRESTMapper
For unit tests, the easiest option is usually to construct a mapper directly.
This gives you a predictable fake mapping environment without requiring discovery from a real API server.
Why This Is Better Than Creating Real Cluster Objects
If the code under test only asks the mapper to resolve a GroupKind or GroupVersionKind, creating fake Pods in a cluster is unnecessary. Real objects test a different layer.
The mapper is about API shape, not workload state. So fake mapping data should model the API surface, not the runtime contents of the cluster.
That distinction makes tests faster and much easier to reason about.
When You Need Discovery-Like Behavior
If your code builds a mapper from API discovery rather than constructing one directly, then your fake data needs to imitate discovery responses. In that case, use a fake discovery client or build test-specific API group resources instead of talking to a real cluster.
The concept is still the same: fake the discovery metadata, not the actual application resources.
For many unit tests, though, DefaultRESTMapper is enough and is much easier to maintain.
What Fake Data to Include
A useful fake mapper entry usually needs:
- group and version
- kind name
- plural resource name
- singular resource name if needed
- namespace or cluster scope
If your production code resolves custom resources, add those explicitly too.
That lets you test CRD-aware logic without installing a CRD into a cluster.
Common Pitfalls
The biggest pitfall is generating fake workload objects when the code under test only cares about type mapping. That makes tests heavier without improving coverage.
Another issue is forgetting resource scope. A mapper entry for a cluster-scoped resource behaves differently from one that is namespaced, and your test should reflect that.
Developers also sometimes add only the kind name and forget the plural resource name, then wonder why REST mapping lookups fail.
Finally, if your production code depends on live discovery behavior, be explicit about that in the test. A handcrafted mapper is ideal for unit tests, but it does not replace full integration tests against a real API server.
Summary
- Fake data for
RESTMappermeans fake API metadata, not fake Pods or Deployments. - '
meta.NewDefaultRESTMapperis a simple way to build deterministic mapper test data.' - Add group, version, kind, resource names, and scope explicitly.
- Use fake discovery only when your code specifically depends on discovery-driven mapper creation.
- Keep mapper tests focused on API mapping behavior instead of full cluster behavior.

