-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Conversation
e70016e
to
ed557bd
Compare
internal/appliance/testdata/golden-fixtures/blobstore-subsequent-disable.yaml
Show resolved
Hide resolved
// More complex test cases involving updates to the configmap can have their own | ||
// test blocks | ||
func (suite *ApplianceTestSuite) TestBlobstoreResourcesDeletedWhenDisabled() { | ||
namespace := suite.createConfigMap("blobstore-default") | ||
suite.Require().Eventually(func() bool { | ||
return suite.getConfigMapReconcileEventCount(namespace) > 0 | ||
}, time.Second*10, time.Millisecond*200) | ||
|
||
eventsSeenSoFar := suite.getConfigMapReconcileEventCount(namespace) | ||
suite.updateConfigMap(namespace, "everything-disabled") | ||
suite.Require().Eventually(func() bool { | ||
return suite.getConfigMapReconcileEventCount(namespace) > eventsSeenSoFar | ||
}, time.Second*10, time.Millisecond*200) | ||
|
||
suite.makeGoldenAssertions(namespace, "blobstore-subsequent-disable") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example of a more bespoke test that updates the configmap after creating it. If we ever find we need to do complex k8s resource upgrades (not just bumping versions), we can hopefully test that in this way.
// Test helpers | ||
|
||
type ApplianceTestSuite struct { | ||
suite.Suite |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: testify/suite doesn't support parallel tests: stretchr/testify#187
If this becomes an issue later, we'll have to switch to a different harness or write our own.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm more than happy to revisit this down the line to get rid of testify (personally not a fan of it), but that's not a high priority 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, apologies for not running this choice by the team before making this PR! I saw it used elsewhere in the monorepo, but of course maybe different teams have different tastes. I personally enjoy it as a lightweight alternative to macro'ing out if... t.Fail()
everywhere 😅
It sounds like you're in favour of merging with testify and revisiting later, but on the other hand if we don't want to use it for assertions, maybe we switch before there's a ton of test code to change? What did you have in mind? 👀
Unpicking the suite stuff won't actually be that hard IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might find github.com/frankban/quicktest to be a nicer alternative if a simple API is all you're looking for
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you talking about as a replacement for assertions, suite orchestration, or both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just for assertion, I'm not much a fan of suites and practicaly never use them. Paired with https://pkg.go.dev/github.com/google/go-cmp/cmp it's a treat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re: suites, this PR only uses the "run this before all tests, not each test" feature. It wouldn't be hard to unpick that, and I might do that. Ironically, the reason testify/suite doesn't support parallelism is that its implementation of "run this before each test" (the feature I'm not using) would create race conditions on the shared state between tests. These tests already share no state between themselves, because I was hoping to be able to run them in parallel 😂
Scheme: scheme.Scheme, | ||
|
||
// On macos with the built-in firewall enabled, every test run will | ||
// cause a firewall dialog box to pop. That's incredibly annoying. This |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently I've pushed a very similar rock up this hill before: kubernetes-sigs/controller-runtime#322 😂
91fcaf9
to
7cd0540
Compare
Ah, the bazel build that passes locally is failing in BK. That's surprising, I'll take a look at that. I probably shouldn't have marked this as ready until I was sure this would work! |
ab8706a
to
ea6b46e
Compare
Use envtest (https://book.kubebuilder.io/reference/envtest.html) to start a real Kubernetes API server, backed by a real etcd instance, in tests. The only controller running is our appliance controller, so these tests assert on the changes our controller actually makes to Kubernetes API objects in response to some input, but don't depend on complex infrastruture like container runtimes or persistent volume controllers (since no such controllers are actually running, unlike in a useful Kubernetes cluster). This commit adds a test harness to the appliance package: * It starts the k8s API server only once, not once per test, as this is a relatively slow operation. * Helper functions to run each test in a unique namespace to avoid inter-test dependency. This opens the door to parallelism, but note that testify/suite doesn't currently support parallel tests. * Helper functions to load input ConfigMaps from fixture files. * Passing `-args appliance-update-golden-files` to `go test` will cause checked-in golden files to be updated.
Fix bazel files and k8s resource tests.
Co-authored-by: Jacob Pleiness <[email protected]>
Co-authored-by: Jacob Pleiness <[email protected]>
This reverts commit 9750e51f36ed0dd37776abf5628733f4dc69164d.
b267688
to
82fd013
Compare
Use envtest (https://book.kubebuilder.io/reference/envtest.html) to start a real Kubernetes API server, backed by a real etcd instance, in tests. The only controller running is our appliance controller, so these tests assert on the changes our controller actually makes to Kubernetes API objects in response to some input, but don't depend on complex infrastruture like container runtimes or persistent volume controllers (since no such controllers are actually running, unlike in a useful Kubernetes cluster).
This commit adds a test harness to the appliance package:
-args appliance-update-golden-files
togo test
will cause checked-in golden files to be updated.See self-review notes below for more info.
Closes https://github.com/sourcegraph/sourcegraph/issues/62015
Test plan
This whole PR is about introducing a new test harness for the appliance component.