-
Notifications
You must be signed in to change notification settings - Fork 31
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
Tech/update jest, babel and adapt mocks #1097
Merged
Merged
Changes from 7 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
284153f
Update jest dependencies
NearW 0ff7a8e
Update babel
NearW be488b2
Fix warning regarding jscore
NearW ca9df7b
Update mocks in test
NearW 74df67b
Update simplified mocks of element and window
NearW c795aa9
Remove deprecated polyfill and use corejs3 instead
NearW 4b32538
Add browserslist to package.json
NearW cb61f70
Merge branch 'master' into tech/update-jest
BridgeAR c8d2f00
Refactor simplified promises
NearW b10fc92
Merge remote-tracking branch 'origin/tech/update-jest' into tech/upda…
NearW File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 suggest to add a linter rule to use the dot notation in the future (if you agree, in a separate PR).
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.
Accessing private fields or functions is quite useful when writing tests or setting up a test.
We could enable that rule for our production code for sure, but tests shouldn't be included.
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.
Using the dot notation is independent from accessing private fields :)
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.
How? When I want to access a private field, I have to use
class["private_field"]
? instead ofclass.private_field
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.
TIL. I was not aware that TypeScript used this specific notation to access private fields. IMO it's a bad practice to access any private field. I do not want to go into that discussion here though. I would actively mark access like these (by adding a comment) that it's a private properly that it's intentionally accessed and that it's the TypeScript way to do so.
Calling something a private field that is still accessible is somewhat weird. The reason that it's working like that was AFAIK that it was difficult to create actual private members when TypeScript came up. That changed in the meanwhile and now JS has actual private fields that do not allow any access from outside.
I personally always test internals by either: using the dependency injection pattern or by just plainly checking the overall output of a higher level API that should only work if the internal path is hit. If the coverage does not show the expected lines to be covered, something is fishy.
To get back to the actual comment: for now it would be possible to exclude tests for such a rule. On the long term, I'd try to refactor the code to the dependency injection pattern.
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.
We could use the typescript-es-lint rule. It has an option to allow private class member access like this.
I'm not sure if you can allow/disallow individual rules. I think you can just define a pattern that applies to all rules.
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 is possible to enable specific rules for specific files by using overrides. It should be sufficient to just use the "native" rule.