-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
feat: define solidity test sources in config #5870
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
b0bdb71
to
8d671af
Compare
980d558
to
9721ff4
Compare
9721ff4
to
c6e7ae9
Compare
c6e7ae9
to
c03c9f7
Compare
c03c9f7
to
c829cb3
Compare
c829cb3
to
4958af2
Compare
4958af2
to
3ce0176
Compare
3ce0176
to
0ebcfbf
Compare
v-next/hardhat/src/internal/builtin-plugins/solidity-test/task-action.ts
Outdated
Show resolved
Hide resolved
v-next/hardhat/src/internal/builtin-plugins/solidity-test/helpers.ts
Outdated
Show resolved
Hide resolved
@@ -257,8 +257,9 @@ describe("HookManager", () => { | |||
_context: HookContext, | |||
givenHre: HardhatRuntimeEnvironment, | |||
): Promise<void> => { | |||
givenHre.config.paths.tests = | |||
"./test-folder-from-plugin1"; | |||
givenHre.config.paths.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.
This is a bit confusing, maybe not needed.
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.
givenHre.config.paths.tests
is of type TestPathsConfig
which is an empty interface to begin with. In this PR, it gets extended by a built-in solidity-test
plugin with a solidity
key. After this, ts starts flagging this assignment as an issue so we can either use something it knows about here or ignore the error.
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.
Oh, I see! the only reason this issue was hit before is because the other plugins that extend TestPathsConfig
are non-builtin.
We chatted about this on a call: we'd treat solidity files as solidity test file if they either end in
Let's default to |
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.
As discussed in a call and on Slack, I made the semantics of paths.tests.solidity
equal to that of mocha
and nodeTest
.
I also removed the noCompile
flag from the solidity test task, moved the common helpers from the test plugin to solidity one, and, most importantly, changed the way in which the tests are discovered (.t.sol
from solidity sources and all .sol
files from solidity test sources).
getAllFilesMatching( | ||
dir, | ||
(f) => f.endsWith(".sol") && !f.endsWith(".t.sol"), | ||
), |
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'm saying here that we should NOT compile .t.sol
files present in solidity sources in the default compile task.
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.
looks good
@@ -257,8 +257,9 @@ describe("HookManager", () => { | |||
_context: HookContext, | |||
givenHre: HardhatRuntimeEnvironment, | |||
): Promise<void> => { | |||
givenHre.config.paths.tests = | |||
"./test-folder-from-plugin1"; | |||
givenHre.config.paths.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.
givenHre.config.paths.tests
is of type TestPathsConfig
which is an empty interface to begin with. In this PR, it gets extended by a built-in solidity-test
plugin with a solidity
key. After this, ts starts flagging this assignment as an issue so we can either use something it knows about here or ignore the error.
{ timeout, noCompile }, | ||
{ timeout, force, quiet }, |
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 decided to remove the noCompile
flag from here until we figure out the right semantics for it.
I also added force
and quiet
flags as they are present in the compile task and make sense here as well.
.addFlag({ | ||
name: "noCompile", | ||
description: "Don't compile the project before running the tests", | ||
name: "force", | ||
description: "Force compilation even if no files have changed", | ||
}) | ||
.addFlag({ | ||
name: "quiet", | ||
description: "Makes the compilation process less verbose", | ||
}) |
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.
Agreed with removing noCompile
.
Now, I'm not sure if these new flags are valuable tbh. And with this names they are definitely confusing, as they are flags to the compilation process, but belong to a test task. I think we should do the same and remove them, at least for now.
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.
OK, no worries. I'll remove them for now.
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 removing noCompile
broke the main test
task, which always sets that param to true for all test subtasks.
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.
Ay! You're right! Sorry about that. I'm on it!
mergeCompilationJobs: shouldMergeCompilationJobs( | ||
hre.globalOptions.buildProfile, | ||
), | ||
quiet, |
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.
quiet should always be true
).flat(1); | ||
|
||
const buildOptions: BuildOptions = { | ||
force, |
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.
force should always be false
.
return; | ||
} | ||
// NOTE: We compile all the sources together with the tests | ||
const rootFilePaths = [...rootSourceFilePaths, ...rootTestFilePaths]; |
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.
No need to compile non-test files, the test files include any necessary non-test file as a dependency already. They aren't acting as root in this usecase.
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 would have sworn that didn't work for me before, but I cannot replicate what I vaguely remember now so I'll remove the rootSourceFilePaths compilation.
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.
Looking good. I left two small comments. Feel about the root files and the task's flags. Feel free to merge after approaching them.
This PR:
solidity
key to thepaths.tests
user config (defaults topaths.sources.solidity
value)compile
task from thetest:solidity
taskpaths.tests.solidity
to thetest:solidity
taskTo compile a subset of sources for solidity tests, I use the build function from the build system programmatically (and prepare required inputs in the solidity test task action).
To make the artifact discovery work properly, I had to add
contractArtifactsGenerated
property to theCacheHitFileBuildResult
. This is because given a compilation job, we need to be able to tell what artifacts were generated, even if that job was cached.One alternative/extension considered was to define the solidity test paths per build profile. This would have allowed greater level of configuration. We decided not to proceed with that, at least for now.