Skip to content

EsLint and Tests fix #67

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

Merged
merged 1 commit into from
Oct 9, 2022
Merged

Conversation

hot9cups
Copy link
Collaborator

@hot9cups hot9cups commented Oct 9, 2022

  • A lot of files had Linting issues. Used EsLint to fix all the troublesome files.
  • Fixed the tests that were failing. Node Tests.js should run just fine now!

- A lot of files had Linting issues. Used EsLint to fix all the troublesome files.
- Fixed the tests that were failing. Node Tests.js should run just fine now!
@hot9cups
Copy link
Collaborator Author

hot9cups commented Oct 9, 2022

Good to see the green check for the lint tests, finally :)

node .\Tests.js too passes all unit tests now!

Copy link
Owner

@ignacio-chiazzo ignacio-chiazzo left a comment

Choose a reason for hiding this comment

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

Nice! super happy to see this!

Could you add to the README file an example of how to run the test locally?

let result = 0;
while (true) {
const replaced = s.replaceAll('01', '10');
for(;;) {
Copy link
Owner

Choose a reason for hiding this comment

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

🤔 is this new? 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah so ESLint triggers lint errors on while(true) because of the constant condition.
for(;;) is allowed though and is seen as a workaround to this (silly) restriction.
Refer this.
We would probably need to add an exception to disable that in the workflow if we would like to disable the check for this. I'm not very sure of that right now but we can have a look at this later.

Copy link
Owner

Choose a reason for hiding this comment

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

oh this is super confusing 😢 but ok for now.

var test = function () {
assert.deepEqual([0,1], twoSum([2,7,11,15], 9));
assert.deepEqual([1,2], twoSum([3,2,4], 6));
assert.deepEqual([0,1], twoSum([3,3], 6));
};

var test2 = function () {
Copy link
Owner

Choose a reason for hiding this comment

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

Can we leave two functions for the two different solutions? That way both cases are isolated.

Copy link
Collaborator Author

@hot9cups hot9cups Oct 9, 2022

Choose a reason for hiding this comment

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

Not really. Infact, the way the file was earlier with two functions, the second function 'test2' was actually not running, so the other solution wasn't even being tested. You can add some console.log statements to confirm the same but you can also have a look directly at the code that corresponds to running the test functions which can be found here. It can be seen that only the 'test' method gets invoked, if we required 'test2' to be invoked we'd have to add that in there.

And what do we do if we have 10 solutions to a problem? I don't think adding 'test2', 'test3', ...'test10' in the main Tests.js file in the test_all function is a good way to do it, besides having to deal with the exception handling for files that do not have the 'testX' method.

So maybe having just one 'test' method and testing every solution to the problem within that method was what came to my mind. Let me know if this reasoning doesn't make sense.

Copy link
Owner

Choose a reason for hiding this comment

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

I personally like to have one test function for a solution so that if there is a bug in a particular solution the specific test fails.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Well ideally I would like that to happen too but I'm not sure how we can achieve that in a clean manner without a lot of hardcoding.

Essentially, we would want to have multiple test functions exported per test file, and somehow loop through all of the functions in the import without knowing the name explicitly.

I haven't coded a lot in JavaScript so I'll need a bit of time to check. I think it's possible to do it though, as the import should be an Object instance so Object.keys might get us what we need.
I'm not super sure so I'll have to experiment and check :D

@hot9cups
Copy link
Collaborator Author

hot9cups commented Oct 9, 2022

Nice! super happy to see this!

Could you add to the README file an example of how to run the test locally?

Right, sure. Did you mean the unit tests though? I believe we already have them - node Tests.js ?

Or was it the linting tests. I'm not sure what's the universal way of doing it. I installed EsLint locally and ran it through the CLI.
I'll add instructions for doing both if that's what you're referring to.

@ignacio-chiazzo
Copy link
Owner

Right, sure. Did you mean the unit tests though? I believe we already have them - node Tests.js ?

Or was it the linting tests. I'm not sure what's the universal way of doing it. I installed EsLint locally and ran it through the CLI.
I'll add instructions for doing both if that's what you're referring to.

Lint tests I meant, we can include the EsLint library in the repository and have a command that runs it locally. Additionally, we can have another command that runs UnitTest and Lint test e.g.

node Test.js // runs all the unit tests. It already exists.
node LintTest // runs all the unit tests.
node test // runs Linter + unit tests. We can rename Test.js with a specific name for unit tests.

@ignacio-chiazzo
Copy link
Owner

I will merge this PR and if you want to tackle that you can do it in a separate PR. Again, thanks for this improvement!

@ignacio-chiazzo ignacio-chiazzo merged commit 04a3e81 into ignacio-chiazzo:master Oct 9, 2022
@hot9cups
Copy link
Collaborator Author

hot9cups commented Oct 9, 2022

Right, sure. Did you mean the unit tests though? I believe we already have them - node Tests.js ?

Or was it the linting tests. I'm not sure what's the universal way of doing it. I installed EsLint locally and ran it through the CLI.
I'll add instructions for doing both if that's what you're referring to.

Lint tests I meant, we can include the EsLint library in the repository and have a command that runs it locally. Additionally, we can have another command that runs UnitTest and Lint test e.g.

node Test.js // runs all the unit tests. It already exists.
node LintTest // runs all the unit tests.
node test // runs Linter + unit tests. We can rename Test.js with a specific name for unit tests.

I think an even better way of doing it would perhaps be having a pre-commit hook that runs the linter before the dev is allowed to commit any code.
I think this is better as it rules out the possibility of the dev forgetting to run the linter, as it gets triggered automatically

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.

2 participants