feat: define solidity test sources in config #5870
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
galargh
force-pushed
the
feat/solidity-test-compilation
branch
from
b0bdb71 to
8d671af
Compare
galargh
force-pushed
the
feat/solidity-test-compilation
branch
2 times, most recently
from
980d558 to
9721ff4
Compare
galargh
force-pushed
the
feat/solidity-test-compilation
branch
from
9721ff4 to
c6e7ae9
Compare
galargh
force-pushed
the
feat/solidity-test-compilation
branch
from
c6e7ae9 to
c03c9f7
Compare
galargh
force-pushed
the
feat/solidity-test-compilation
branch
from
c03c9f7 to
c829cb3
Compare
galargh
force-pushed
the
feat/solidity-test-compilation
branch
from
c829cb3 to
4958af2
Compare
galargh
force-pushed
the
feat/solidity-test-compilation
branch
from
4958af2 to
3ce0176
Compare
galargh
force-pushed
the
feat/solidity-test-compilation
branch
from
3ce0176 to
0ebcfbf
Compare
galargh
changed the title
| @@ -161,6 +161,11 @@ const config: HardhatUserConfig = { | |||
| tests: { | |||
| mocha: "test/mocha", | |||
| nodeTest: "test/node", | |||
| solidity: [ | |||
| "contracts/Counter.sol", | |||
There was a problem hiding this comment.
The semantics of this are slightly different than what the other tests entries use. Here this is "files to be compiled", while the others are "folders where tests can be found".
If we use the rules to find solidity tests files discussed in my other comment, the "folders" approach makes more sense.
| } | ||
| }), | ||
| hre.config.paths.tests.solidity | ||
| .map((p) => resolveFromRoot(hre.config.paths.root, p)) |
There was a problem hiding this comment.
This would change based on the other comments
| // NOTE: The uncached sources will still be compiled event if `noCompile` | ||
| // is true. We could consider adding a `cacheOnly` option to support true | ||
| // `noCompile` behavior. | ||
| force: !noCompile, |
There was a problem hiding this comment.
If I run npx hardhat test solidity it will force and recompile everything
There was a problem hiding this comment.
Maybe add an issue and address it after we have the compilation cache in place, and when we have the split between production and test compilation caches or while implementing that.
There was a problem hiding this comment.
We should also consider removing this option
| * It throws a HardhatError if the build results indicate that the compilation | ||
| * job failed. | ||
| */ | ||
| export function throwIfSolidityBuildFailed( |
There was a problem hiding this comment.
For a future PR: we should use the same implementation here and during compile.
There was a problem hiding this comment.
mostly to have a consistent ui
| @@ -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.
This is a bit confusing, maybe not needed.
|
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 |
This PR:
soliditykey to thepaths.testsuser config (defaults topaths.sources.solidityvalue)compiletask from thetest:soliditytaskpaths.tests.solidityto thetest:soliditytaskTo 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
contractArtifactsGeneratedproperty 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.