-
Notifications
You must be signed in to change notification settings - Fork 25
Refactor of ExpressJS files #174
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
Conversation
This pull request introduces 1 alert and fixes 1 when merging b589964 into 1e6c692 - view on LGTM.com new alerts:
fixed alerts:
|
Codecov Report
@@ Coverage Diff @@
## dev #174 +/- ##
==========================================
+ Coverage 83.93% 85.84% +1.91%
==========================================
Files 7 19 +12
Lines 473 657 +184
Branches 104 132 +28
==========================================
+ Hits 397 564 +167
- Misses 69 84 +15
- Partials 7 9 +2
Continue to review full report at Codecov.
|
package.json
Outdated
@@ -24,6 +24,7 @@ | |||
"test_network_down": "docker-compose -f ./__tests__/integration/docker-compose.yml down", | |||
"dev": "nodemon --exec babel-node index.js", | |||
"start": "babel-node src/index.js", | |||
"lint": "eslint . --fix", |
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.
Shouldn't we run this in Github Actions? (without the --fix
option, maybe)
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.
Good idea! Done on 318dad2
8df9845
to
9a10bb1
Compare
Codecov Report
@@ Coverage Diff @@
## dev #174 +/- ##
==========================================
+ Coverage 83.93% 85.78% +1.84%
==========================================
Files 7 19 +12
Lines 473 647 +174
Branches 104 132 +28
==========================================
+ Hits 397 555 +158
- Misses 69 83 +14
- Partials 7 9 +2
Continue to review full report at Codecov.
|
src/routes/wallet.routes.js
Outdated
*/ | ||
walletRouter.get( | ||
'/address-index', | ||
query('address').isString(), |
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.
What method is being executed here? If we still don't have tests for this route, we should add it (not in this PR, of course).
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.
This missing method is what was causing errors on the integration tests for send-tx
. I agree we should add integration tests dedicated to these basic address routes in the near future to improve our coverage.
This was fixed on d829feb
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.
Can you create an issue for these tests that don't exist?
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.
Created issue #176 - Create tests for basic query routes
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 like the organization but some files were src/<section>/<name>.<section>.js
and it felt repetitive.
Do you think we should remove the second <section>
? Or is there any reason to keep it?
# This file is required by most controllers and triggers "import/no-unresolved" if missing | ||
- name: Copy config file | ||
run: cp ./__tests__/integration/configuration/config-fixture.js ./src/config.js | ||
|
||
- name: Lint | ||
run: npm run lint |
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.
Why not just add these steps before testing on the main workflow?
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.
Since our tests are currently not green, I tried to create the minimum possible interference with them. So I created a new workflow yml.
But now that you mention, I see our wallet mobile follows this practice of running the lint within the main
workflow.
I agree that's a good idea, but I would rather make all tests green before making this move.
What do you think?
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 think the interference caused by linters is not that big. We will be able to differentiate failures caused by them or by the tests.
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 tried adding the linter to the main workflow on a555448, but it broke when tried to run on Node 8.x, possibly also on 10.x
We could use additional actions or configurations to enable the linting only on specific node versions, but I think there is little benefit for this extra complexity.
Do you have any suggestions on this?
@@ -6,10 +6,10 @@ on: | |||
- dev | |||
tags: | |||
- v* | |||
pull_request: |
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.
Unrelated to line
What's your opinion on running the integration tests after unit tests (on the main workflow)?
If the unit tests fail we don't need to run integration.
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 like the idea of only running the integration tests after the unit ones, but maybe not on the same workflow.
Both tests have a timeout of 40 minutes and generate great amounts of logs. While we're trying to fine tune them, I think it's more helpful to keep them on isolated runs with separate outputs. The cost benefit may not be a relevant trade-off for the isolation of problems while in active development.
I think that with some optimizations on the headless, the tests and the underlying lib we could join those tests in the future. But while we don't get to that point, maybe other solutions like the wait on check action or the workflow_run
property could be good alternatives to this ordering of actions.
What do you think?
setupTests-integration.js
Outdated
/* eslint-disable global-require */ | ||
import * as Path from 'path'; |
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.
Maybe import only parse
since it's the only one used.
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.
Good point. Done on e0b7301
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 guess the idea with this import change is that you would be able to remove the comment above that disables the lint check. /* eslint-disable global-require */
I think you should remove it now that you've changed the import.
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.
Actually this global-require
is there because of lines 22 and 33, and it's still required.
This issue is being discussed on a thread below about the other setup file, but the reasons are the same.
/* eslint-disable import/no-extraneous-dependencies,global-require */ | ||
import TestUtils from './__tests__/test-utils'; |
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.
Why not remove this?
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.
These are lint rules that I found it better to ignore for now, since fixing them could create confusion or take too long to investigate the proper way to implement them:
import/no-extraneous-dependencies
This accuses the mock-socket
dependency to be not explicitly declared on the package.json
dependencies. Looking at the rules we follow from airbnb-base
, I see that the setup filename we've chosen is not within their convention.
At a future time we could move the setup files into the __tests__
folder and this would be solved.
global-require
On lines 18
and 29
we require javascript files within a very controlled clojure scope on Jest. If we imported these files into global variables and tried to use them in the mock factory
method, we would get the following error:
babel-plugin-jest-hoist: The module factory of `jest.mock()` is not allowed to reference any out-of-scope variables.
* LICENSE file in the root directory of this source tree. | ||
*/ | ||
|
||
// TODO: Make this a map instead of a common object. It's safer. |
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.
TODO
on this PR or for 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.
To do later. This is a comment to reinforce this Use of externally-controlled format string
issue raised by LGTM bot.
src/routes/wallet.routes.js
Outdated
*/ | ||
walletRouter.post('/stop', stop); | ||
|
||
walletRouter.use('/tx-proposal', txProposalRouter); |
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.
Maybe put this after the middleware on the start of the file.
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.
Done on e0b7301
@r4mmer about both the file name and the folder containing the I believe the idea is to help when the developer is working on multiple levels of the same part of the project. For example, instead of having three One example of this file structure is found on this article about ExpressJS project structures from 2020, and one example of a project boilerplate is on this repository of good practices last updated on 2021. |
This reverts commit a555448. The linter is not working on Node 8.x
This PR aims to refactor this Express application into a more conventional format of separating files into routes, controllers and services.
Acceptance Criteria
Risks and compromises
At the current state of the Integration Tests, the test results are sometimes failing due to timeouts and other minor failures related to excessive CPU consumption.
There are also some issues with the code coverage, raised by lgtm-com, that existed before this refactor and are outside its scope to change.
On commit 91be24f changes were made to the configurations to make most possible test pass. All tests not described below were passing at the time of that commit, which indicates the refactor was successful in not changing the application logic.
These changes were reverted on f628571 to ensure this PR is within its scope.
Failing Tests
Risks of merging with these failures
Both failures are still being investigated. But since the multisig feature is being blocked on the
constants
file, these failures pose no immediate risk to the users should this code reach production. Their errors have been pinpointed on the test results for 91be24f to be these:{"success":false,"error":"OP_CHECKSIG: failed\nOP_CHECKSIG: failed\nOP_CHECKSIG: failed\nOP_CHECKSIG: failed\nStack left with more than one value"}
{"success":false,"error":"OP_DUP: empty stack"}
Security Checklist