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

tapdb+mssmt: update mssmt unit tests to run against all registered db backends #770

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Roasbeef
Copy link
Member

Before this PR, we had the logic to execute all registered dbs, but didn't actually register them all. With this PR, we now call RegisterTreeStore.

By default the mssmt unit tests will run sqlite. You an run postgres with this build tag: -tags=test_db_postgres.

This works for both sqlite and postgres. Unlike the existing routines, we don't need to pass in a testing.T and instead want to just return an error.
We use the new `activeTestDB` variable to set the proper DB driver name.
The function will now emit all the registered db drivers vs just special casing for sqlite.
@guggero guggero self-requested a review January 22, 2024 08:10
Copy link
Member

@guggero guggero left a comment

Choose a reason for hiding this comment

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

Nice to have all tests running in the Postgres environment again! I think we at some point disabled them because they took very long compared to SQLite. But since they seem to discover an issue I guess it's good to turn them on again.

@@ -402,3 +402,38 @@ func (t *taprootAssetTreeStoreTx) UpdateRoot(rootNode *mssmt.BranchNode) error {
Namespace: t.namespace,
})
}

func init() {
Copy link
Member

Choose a reason for hiding this comment

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

Should this really be in the non-test code? Since it's only used by unit tests and does spin up an ephemeral container in the Postgres case?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point re test code vs non test code. I'd need to double check, but I don't think an init is run in a _test.go when a package is imported.

Re postgres container: this'll only happen if the New method of the driver is called (won't be created unconditionally).

@@ -173,6 +173,25 @@ func NewTestPostgresDB(t *testing.T) *PostgresStore {
return store
}

// NewPostgresDB is a helper function that creates a Postgres database for
// testing.
func NewPostgresDB() (*PostgresStore, error) {
Copy link
Member

Choose a reason for hiding this comment

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

See my other comment about moving the driver registration into a test file. Then we can perhaps create the empty var t testing.T there and still accept it as a parameter here?
Really looks weird having this as non-test code and initialize that variable... Also would allow us to use t.Cleanup() for the sqlFixture.TearDown().

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah the testing.T was a bit of a hack so I could get things working to be able to write the tests that prompted this PR in the first place.

I don't think we want to move the driver init into a test fie though, as this was created so we could write tests in the mssmt package that span all our db versions. Postgres is a bit unique in that it wants an ephemeral container active. We could have the test (which lives in mssmt) create the container itself, but then those details would leak into a package that's only concerned about the mssmt abstraction.

@dstadulis
Copy link
Collaborator

!lightninglabs-deploy mute 720h30m

@dstadulis
Copy link
Collaborator

!lightninglabs-deploy unmute

@dstadulis dstadulis modified the milestones: v0.4, v0.4.1 May 20, 2024
@dstadulis
Copy link
Collaborator

!lightninglabs-deploy mute 360h

1 similar comment
@dstadulis
Copy link
Collaborator

!lightninglabs-deploy mute 360h

@Roasbeef Roasbeef modified the milestones: v0.4.2, v0.5 Aug 19, 2024
@lightninglabs-deploy
Copy link

@Roasbeef, remember to re-request review from reviewers when ready

@guggero
Copy link
Member

guggero commented Sep 10, 2024

!lightninglabs-deploy mute

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 👀 In review
Development

Successfully merging this pull request may close these issues.

4 participants