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: setup tests #37

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

test: setup tests #37

wants to merge 6 commits into from

Conversation

xDivisionByZerox
Copy link
Member

Description

Setup tests, using vitest, for the project.

@xDivisionByZerox xDivisionByZerox added c: infra Changes to our infrastructure or project setup c: test Improvements or additions to test files labels Dec 20, 2023
@xDivisionByZerox xDivisionByZerox self-assigned this Dec 20, 2023
Copy link
Member

Choose a reason for hiding this comment

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

I think you could remove the overrides block, because you have no rules in the top group anyway.

I would also recommend adding the vitest-eslint config from the main repo:

https://github.com/faker-js/faker/blob/3649b89e928873d26d2791e1bf7f4979af083e9b/.eslintrc.js#L176-L194

Comment on lines 11 to +13
"format": "prettier src --write",
"lint": "eslint src",
"lint:fix": "eslint src --fix"
"lint:fix": "eslint src --fix",
Copy link
Member

Choose a reason for hiding this comment

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

IMO these should also apply to the test folder/all files.

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 👍

@@ -51,7 +52,8 @@
"@typescript-eslint/parser": "^6.14.0",
"eslint": "^8.56.0",
"prettier": "^3.1.1",
"typescript": "~5.3.3"
"typescript": "~5.3.3",
"vitest": "^0.34.3"
Copy link
Member

Choose a reason for hiding this comment

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

Maybe also add eslint-plugin-vitest.

Copy link
Member Author

Choose a reason for hiding this comment

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

Would that not be a searate concern that "setup tests" is?

Copy link
Member

Choose a reason for hiding this comment

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

I would do it, but I don't consider it required.
If you add something new, you can also change directly related stuff like also edited the eslint config files.
IMO there is no big difference in adding the lint library for the tests and configuring the linter to run on tests.
Maybe do a full lint setup in a separate PR (Potentially just copy pasting the config from the main repo). 🤷

Comment on lines +74 to +78
const IGNORE_MODULES: LiteralUnion<keyof Faker>[] = [
'_randomizer',
'definitions',
'rawDefinitions',
];
Copy link
Member

Choose a reason for hiding this comment

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

All other constants are defined in file scope instead of method local scope.
IMO we should keep it consistent.

Copy link
Member Author

Choose a reason for hiding this comment

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

I was thinking about that, but the constants which I left in function scopes are only used there. You think consistency is more important than encapsulation?

Copy link
Member

@ST-DDT ST-DDT Dec 20, 2023

Choose a reason for hiding this comment

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

This is just my personal preference. IMO being file scoped is encapsulated enough. I also consider it helpful to list all data sets in one place, so that is easier to see what filters/data exist. This is part of my normal attempts to separate data from function, if they are too big to inline.

Comment on lines +98 to +99
const moduleRef = REMOVED_METHODS[moduleKey] ?? [];
return moduleRef.includes(entryKey);
Copy link
Member

Choose a reason for hiding this comment

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

In line 82 you check the value directly, I think you could do that here as well.

Suggested change
const moduleRef = REMOVED_METHODS[moduleKey] ?? [];
return moduleRef.includes(entryKey);
return REMOVED_METHODS[moduleKey]?.includes(entryKey);

Copy link
Member Author

Choose a reason for hiding this comment

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

Note that your code will not result in the same value if moduleKey does not exist on REMOVED_METHODS. It will return undefined instead of false.

Copy link
Member

Choose a reason for hiding this comment

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

Then add ?? false

Comment on lines +92 to +96
const REMOVED_METHODS: {
[module: string]: ReadonlyArray<string>;
} = {
random: ['locale'],
};
Copy link
Member

Choose a reason for hiding this comment

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

Same here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: infra Changes to our infrastructure or project setup c: test Improvements or additions to test files
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants