-
Notifications
You must be signed in to change notification settings - Fork 2
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: add coderd_user resource #18
Conversation
Co-authored-by: Ethan Dickson <[email protected]>
// Copyright (c) HashiCorp, Inc. | ||
// SPDX-License-Identifier: MPL-2.0 | ||
|
||
package provider |
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.
This kinda doesn't work because it requires either a mocked client or a real server to connect to. At that point, we might as well go all in on integration tests since they're easier to write.
@@ -50,11 +52,33 @@ func TestIntegration(t *testing.T) { | |||
assertF func(testing.TB, *codersdk.Client) | |||
}{ | |||
{ | |||
name: "example-test", | |||
name: "user-test", |
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.
To me, it just seems like these integration tests accomplish the same thing as the acceptance test in user_resource_test.go
, yet they're way more complicated. I think the integration tests probably make more sense for chaining resources together or something.
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 unclear from your comment what you want to happen. Do you want us to use the integration tests or the resource tests? The resource tests will take effort to get working (most likely some mocking stuff, and we might not be able to use the hashi test framework)
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 feel like you could easily start a coderd pod in the resource tests similar to whats going on here and accomplish the same thing without having to mock anything. It also doesn't seem like we're testing read/update/delete/import here either, which the resource test just has natively. We're also not able to assert any of the terraform state here.
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.
Sure, can we do that in a follow up though?
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.
shore
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.
If we're going to start a coderd
pod for acceptance tests, why not just import coderdtest
?
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's not much of a difference, but running a container is better because it auto updates for us lol
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.
yeah plus we'll need to copy the gomod replaces and keeping that in sync seems like more of a headache
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.
yeah agreed that's super annoying, let's not do that
Adds
resource "coderd_user"
Relates to #2