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: Move integration tests to separate package #2111

Merged
merged 25 commits into from
Oct 11, 2023

Conversation

sfc-gh-asawicki
Copy link
Collaborator

@sfc-gh-asawicki sfc-gh-asawicki commented Oct 10, 2023

This is the first PR to have SDK integration tests in a separate package. It is based on PoC: #1989.

It was essential to move the tests fast so that we could work on them in isolation and that there were not many strange conflicts to resolve. A few issues will be handled in subsequent PRs; they are described below.

Changes

  • (Almost) all integration tests moved to separate package
    • setup I contained in the setup_integration_test.go file. It introduces two temporary methods, testClient and testContext, allowing easier test transition to the separate package. They should be inlined in subsequent changes.
    • client_integration_test.go was left in the SDK package because this test is a bit different; it tests the client itself and not any resource in particular; therefore, its setup and behavior are different (I think it should be left there).
    • This required prefixing some of the methods with sdk..
    • Some unexported methods were needed in tests (and helpers), so they had to be exported somehow. To avoid big renames throughout the SDK package in this PR, they were copied/exported by delegating in the integration_test_imports.go file. The file contains a description; it will be one of the issues that must be handled in subsequent PRs.
    • helper_test.go were almost completely moved to integration_tests/helpers.go file. Some methods are still needed in the SDK package (for sweepers and the aforementioned client_integration_test.go). It may change when we decide what to do with the sweepers.
    • Two new precisely the same files, random.go, were introduced in both packages. We need to decide how to handle the need to have randomly generated content in both the sdk and integration_tests packages. A comment is left in the random.go file in the integration_tests package.

Next steps (for subsequent PRs) - summarized:

  • decide what is the right way to reuse client throughout the tests (currently accessor function testClient vs. itc.client vs. top-level client vs. something else?); the same with the testContext function
  • deal with the contents of integration_test_imports.go file
  • deal with two random.go files
  • decide what to do with sweepers
  • the tests were only moved, and so the common setup was not extracted:
    • we can extract setting up database/schema to the testMain method
    • we can merge separate functions in a single file to have less setup steps

Test Plan

  • unit tests (nothing should break)
  • integration tests (the essence of the tests was not changed, so they should pass)
  • acceptance tests (nothing should break)

References

@github-actions
Copy link

Integration tests success for 4fd8e4fa3258e35a37e2be50b62c818ea2f8de5b

@github-actions
Copy link

Integration tests failure for 37b78520d7eb6d18e311bc04feb828aac5e20e90

@github-actions
Copy link

Integration tests success for f817192c25530d9f7156a78a219968adf4cf1a9d

@sfc-gh-asawicki sfc-gh-asawicki marked this pull request as ready for review October 11, 2023 07:54
// This will be handled in subsequent PRs, so that the main difficulty (moving) is already merged.

var (
ErrObjectNotExistOrAuthorized = errObjectNotExistOrAuthorized
Copy link
Collaborator

Choose a reason for hiding this comment

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

i don't have an issue making errors public

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As discussed I will do it in separate PR.

)

// ExecForTests is an exact copy of exec (that is unexported), that some integration tests/helpers were using
func (c *Client) ExecForTests(ctx context.Context, sql string) (sql.Result, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

looks like it is only for tags / tables. both of which could be refactored to use the createTag() and createTable() `test helper functions. I don't like exporting this function, but it is okay for temporary

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, it's just temporary, I didn't want to do refactoring in this PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As discussed I will do it in separate PR.

}

// GetName is just an accessor to unexported name field
func (r *CreateNetworkPolicyRequest) GetName() AccountObjectIdentifier {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Looks like we could have the helper functions which create network policy / other test objects also return the id. e.g. req, name := getDefaultNetworkPolicy(). So that way we do not need these getter functions. However, there is also no particular reason not to support getter functions. Perhaps we should add getter functions for all the request objects.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I will add it to our generator improvement doc, to generate at least a getter for the name for now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As discussed I will do it in separate PR.

}

// GetAccountLocator is an accessor to unexported accountLocator, which is needed in some tests
func (c *Client) GetAccountLocator() string {
Copy link
Collaborator

Choose a reason for hiding this comment

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

i don't have a problem moving this to the config.go file. I think this plus the GetConfig() function are useful in general, not just for int tests.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As discussed I will do it in separate PR.

return c.config
}

// FindOne just delegates to our util findOne from SDK
Copy link
Collaborator

Choose a reason for hiding this comment

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

i guess this begs the questions: should we move such helper functions into their own package, and have them all be exported? i don't see why not.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we can consider using internal packages for utils / helpers and other similar packages.
Here's more on internal packages - https://go.dev/doc/go1.4#internalpackages

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, that's what I would also recommend for this particular one. @sfc-gh-jcieslak do you agree?

Still, I would prefer to work on the contents of this file in subsequent PR to not inflate this PR any further (which would happen by using extracted util in existing places).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As discussed I will do it in separate PR.

pkg/sdk/integration_tests/accounts_integration_test.go Outdated Show resolved Hide resolved
@github-actions
Copy link

Integration tests failure for 652a4b0df54514c678ef906d47000dc7418b662e

@github-actions
Copy link

Integration tests success for 652a4b0df54514c678ef906d47000dc7418b662e

@github-actions
Copy link

Integration tests failure for 7a6f781fbb6b2b49f2f028c6ba8a7df66eb19290

2 similar comments
@github-actions
Copy link

Integration tests failure for 7a6f781fbb6b2b49f2f028c6ba8a7df66eb19290

@github-actions
Copy link

Integration tests failure for 7a6f781fbb6b2b49f2f028c6ba8a7df66eb19290

@github-actions
Copy link

Integration tests success for 7a6f781fbb6b2b49f2f028c6ba8a7df66eb19290

@github-actions
Copy link

Integration tests success for e9e60722013c629a8a5996c9490401a74f611305

@sfc-gh-asawicki sfc-gh-asawicki merged commit 2755589 into main Oct 11, 2023
8 checks passed
@sfc-gh-asawicki sfc-gh-asawicki deleted the move-integration-tests-to-separate-package branch October 11, 2023 16:23
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

3 participants