Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: Integration testing with testcontainers go #1076

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

flowchartsman
Copy link
Contributor

@flowchartsman flowchartsman commented Aug 13, 2023

Motivation

Instead of building a customized container, test using base image and testcontainers-go. This enables manual individual test execution, and will only create the integration container if tests are run which require it.

Modifications

  • Integration container singleton using testcontainers-go
  • Modify helper URLs to pull from mapped ports on integration container, ensuring that only tests which access these URLS will cause the integration container to get created.

Verifying this change

cd <repo root>/pulsar && go test -v -race ./...

  • Make sure that the change passes the CI checks.

This change is already covered by existing integration tests.

Does this pull request potentially affect one of the following parts:

Documentation

  • Does this pull request introduce a new feature? no
  • If yes, how is the feature documented? not applicable
  • If a feature is not applicable for documentation, explain why?
    • this is a test-only feature

WIP

Some connection tests are failing, such as the "retry on multipl hostname" or producer connection tests, however it's unclear how these changes would suddenly cause this test to fail, so it's possible these are flakey.

Tasks:

  • Collect output with go test -v and compare against vanilla repo in an attempt to identify tests that are passing, but shouldn't, and determine of the above errors are flakey tests or something different about the testcontainers-go environment
  • allow container to (optionally) persist for local iteration on a single test or feature

WIP Checkin - most tests passing, but reconnect logic seems flakey
@flowchartsman flowchartsman changed the title Feat: Integration teting with testcontainers go Feat: Integration testing with testcontainers go Aug 13, 2023
@flowchartsman
Copy link
Contributor Author

Some other benefits:

  • no need for scripts in the happy pathway; the container is automatically created if needed and torn down after testing is complete
  • code doesn't need to be copied into the container and built for every change, and with a little modification, the container could be made to persist by disabling the reaper container through the use of an environment variable or even a go run style container invocation allowing fast iteration on a single test or feature.
  • the integration container and associated helper functions could be moved into another package, or even another module entirely, which would allow projects based on pulsar-client-go to use the same testing infrastructure. In particular, I'm thinking about [go]: reduce dependency #819, which would split pusar-perf into its own repo. Even though this particular code path does not do IT, it potentially could do so by using the shared IT container code from the main repo.

@flowchartsman
Copy link
Contributor Author

Pending the changes in #1077, this PR might end up getting reworked such that the following code in helper_for_test.go

func serviceURL() string {
	return integration.URL("pulsar", "6650")
}

func serviceURLTLS() string {
	return integration.URL("pulsar+ssl", "6651")
}

func webServiceURL() string {
	return integration.URL("http", "8080")
}

func webServiceURLTLS() string {
	return integration.URL("https", "8443")
}

Becomes

AdminClient() *pulsaradmin.Client {
        return pulsaradmin.NewClient(pulsaradmin.ClientConfig{
		WebServiceURL:   integration.URL("https", "8443"),
		BKWebServiceURL: integration.URL("pulsar", "6650"),
                //etc
	})
}

AdminClientTLS() *pulsaradmin.Client {
        return pulsaradmin.NewClient(pulsaradmin.ClientConfig{
		WebServiceURL:   integration.URL("http", "8080"),
		BKWebServiceURL: integration.URL("pulsar+ssl", "6651"),
                //etc
	})
}

Which would then create the integration container only when one of the helper admin clients is used, while simultaneously dogfooding pulsar/pulsaradmin and increasing coverage. Which would be pretty darn slick.

"github.com/stretchr/testify/assert"

pkgerrors "github.com/pkg/errors"
)

const (
serviceURL = "pulsar://localhost:6650"
serviceURLTLS = "pulsar+ssl://localhost:6651"
// serviceURL = "pulsar://localhost:6650"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove these instead of commenting out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants