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

test: Test node pkg constructor via integration test suite #2641

Merged
merged 5 commits into from
May 22, 2024

Conversation

AndrewSisley
Copy link
Contributor

Relevant issue(s)

Resolves #2634

Description

Tests node pkg constructor via integration test suite instead of bypassing it and directly creating db instances via the db package.

Will be used by our tests shortly, can also be used by users at somepoint too IMO.
Instead of the db constructor directly - before it was bypassing the main public (embedded) entry point to our codebase leaving it untested.  I also think the new test code is slightly nicer.

The switch statement was copied from the `NewBadgerFileDB` function above.
Was a bit annoying to get rid of, and easy to simplify
@AndrewSisley AndrewSisley added area/testing Related to any test or testing suite code quality Related to improving code quality labels May 22, 2024
@AndrewSisley AndrewSisley added this to the DefraDB v0.12 milestone May 22, 2024
@AndrewSisley AndrewSisley requested a review from a team May 22, 2024 14:02
@AndrewSisley AndrewSisley self-assigned this May 22, 2024
@AndrewSisley AndrewSisley changed the title tests: Test node pkg constructor via integration test suite test: Test node pkg constructor via integration test suite May 22, 2024
Was a bit annoying to get rid of, and easy to simplify
Copy link
Collaborator

@fredcarle fredcarle left a comment

Choose a reason for hiding this comment

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

Good idea to move to the new constructor. Just one thought to remove a bit of confusion from the added StoreOption field.

)

// StoreOptions contains store configuration values.
type StoreOptions struct {
path string
inMemory bool
defraStore bool
Copy link
Collaborator

Choose a reason for hiding this comment

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

thought: inMemory and defraStore are also synonyms. Maybe we could do this instead.

type Datastore int

const (
  BadgerFile Datastore = iota
  BadgerMemory
  DefraMemory 
)

type StoreOption struct {
  ...
  store Datastore
}

This way by default it will be BadgerFile and if we add more option we won't need more struct fields and we remove the memory store confusion.

Copy link
Member

Choose a reason for hiding this comment

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

+1 for the thought

Copy link
Contributor Author

@AndrewSisley AndrewSisley May 22, 2024

Choose a reason for hiding this comment

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

I was tempted by that initially, but I felt defra-store was more analogous to badger-store, and thus (at least long-term) both inMemory and path would be applicable to both, is just that defra-store has no file based implementation yet (and so also atm, always assumes inMemory is true).

If/when we support more stores, defraStore should be replaced by an enum that contains other store implementations (defra, badger, turtle, etc, etc), all of which can respect path and inMemory (saves multiplying the number of db-types)

Copy link
Collaborator

Choose a reason for hiding this comment

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

That leaves a point of confusion thought as turtle or others might not support in memory store but the option would still be available. So leaving it as is in the short term creates confusion between the badger in memory and defra in memory options and in the long term leaves in an option that might be irrelevant for some stores. I do have a preference to remove the confusion but I'm not blocking the PR for this.

Copy link
Member

@shahzadlone shahzadlone left a comment

Choose a reason for hiding this comment

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

Cheers

@AndrewSisley AndrewSisley merged commit d10d5a6 into sourcenetwork:develop May 22, 2024
28 of 29 checks passed
@AndrewSisley AndrewSisley deleted the 2634-int-test-node branch May 22, 2024 15:24
AndrewSisley added a commit that referenced this pull request May 23, 2024
## Relevant issue(s)

Resolves #2643

## Description

Don't setup http and p2p by default in test suite.

This is a regression I introduced in
#2641 (sorry for the
bother) - we set p2p and http up later. As the new, unused, P2P and http
servers werent cleaned up at the end of the test, this had quite a bad
effect on test suite memory consumption.

Later, I think the surrounding code that sets up p2p and http could
probably be changed later to make better use of `node.New`, but IMO this
is good enough for now (we have other things to do).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/testing Related to any test or testing suite code quality Related to improving code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Integration tests bypass most of node package
3 participants