refactor: move endpoint- and source-utils out of shared package

[bachorp]

What does it do ?

Moves endpoint- and source-related test utils out of testutils into the respective package.

Motivation

To allow utils to be used from endpoint and source packages (otherwise there would be a circular import).

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign ivankatliarchuk for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @bachorp. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ivankatliarchuk]

/ok-to-test

[ivankatliarchuk]

Currently, there are no circular imports in the project, so it’s not entirely clear what problem this refactor is trying to solve. I do agree that some of the refactorings or improvements may be hard and introduce some level of coupling and circular dependencies, but in most cases this is due not to respect components boundaries.

One of the original reasons for introducing testutils was to isolate test-related utilities from the actual production interfaces (e.g., endpoint and source). With this PR, we now end up mixing test utilities and real interfaces in the same package, which I don’t see as an improvement.

##Concerns

Mixing concerns
By placing test helpers directly into the endpoint and source packages, they become part of the public interface of those packages. This blurs the line between runtime code and testing scaffolding, which is confusing for maintainers and downstream consumers.

Risk of circular dependencies
If we ever move utils into source/testutils or endpoint/testutils, there’s a chance it will trigger circular dependencies. That’s usually why Go projects adopt an internal/testutils/... structure.

I think alternative structure need to be proposed

Example; If the goal is to group test-related utilities closer to their domain, here are two clean approaches:

Option 1: Use domain-specific test packages

external-dns/
├── source/
│   ├── ... (core source code)
│   └── testutils/   # test helpers for sources
├── endpoint/
│   ├── ... (core endpoint code)
│   └── testutils/   # test helpers for endpoints

Option 2: Centralize under internal/testutils

external-dns/
├── internal/
│   └── testutils/
│       ├── source/    # source-specific test helpers
│       └── endpoint/  # endpoint-specific test helpers
├── source/
│   └── ... (core source code)
├── endpoint/
│   └── ... (core endpoint code)

Regardless, of an end solution, here are the requirements from my point of view

• Keeps test scaffolding out of the public API.
• Avoids circular dependencies in source or endpoint.
• Provides a consistent home for test helpers across the codebase.

[bachorp]

@ivankatliarchuk You're right. For some reason I thought this would be required to implement the unit test for #5788 as suggested.
So this is required only if one wouldn't want to have tests also in testutils. I can reiterate in case maintainers think that would be a worthy improvement and will otherwise not pursue this further.