Skip to content
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

Merged
merged 12 commits into from
Jan 13, 2025

Conversation

galargh
Copy link
Member

@galargh galargh commented Oct 28, 2024

  • Because this PR includes a bug fix, relevant tests have been included.
  • Because this PR includes a new feature, the change was previously discussed on an Issue or with someone from the team.
  • I didn't do anything of this.

This PR:

  • adds a solidity key to the paths.tests user config (defaults to paths.sources.solidity value)
  • removes the dependency on the compile task from the test:solidity task
  • adds compilation of paths.tests.solidity to the test:solidity task

To 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 the CacheHitFileBuildResult. 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.

Copy link

vercel bot commented Oct 28, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
hardhat ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 13, 2025 11:13am

Copy link

changeset-bot bot commented Oct 28, 2024

⚠️ No Changeset found

Latest commit: 1277665

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@github-actions github-actions bot added the status:ready This issue is ready to be worked on label Oct 28, 2024
@alcuadrado alcuadrado added the v-next A Hardhat v3 development task label Oct 28, 2024
@galargh galargh changed the title [WIP] feat: define solidity test sources in config feat: define solidity test sources in config Dec 4, 2024
@galargh galargh requested a review from alcuadrado December 4, 2024 11:24
@galargh galargh marked this pull request as ready for review December 4, 2024 11:24
@@ -257,8 +257,9 @@ describe("HookManager", () => {
_context: HookContext,
givenHre: HardhatRuntimeEnvironment,
): Promise<void> => {
givenHre.config.paths.tests =
"./test-folder-from-plugin1";
givenHre.config.paths.tests = {
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

@alcuadrado
Copy link
Member

We chatted about this on a call: we'd treat solidity files as solidity test file if they either end in .t.sol, or they are inside config.paths.tests.

(defaults to paths.sources.solidity value)

Let's default to test/.

Copy link
Member Author

@galargh galargh left a 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).

Comment on lines +81 to +84
getAllFilesMatching(
dir,
(f) => f.endsWith(".sol") && !f.endsWith(".t.sol"),
),
Copy link
Member Author

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.

Copy link
Member

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 = {
Copy link
Member Author

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.

Comment on lines 19 to 28
{ timeout, noCompile },
{ timeout, force, quiet },
Copy link
Member Author

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.

@galargh galargh requested a review from alcuadrado January 7, 2025 13:55
Comment on lines 23 to 30
.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",
})
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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,
Copy link
Member

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,
Copy link
Member

@alcuadrado alcuadrado Jan 12, 2025

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];
Copy link
Member

@alcuadrado alcuadrado Jan 12, 2025

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.

Copy link
Member Author

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.

Copy link
Member

@alcuadrado alcuadrado left a 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.

@galargh galargh enabled auto-merge January 13, 2025 11:13
@galargh galargh added this pull request to the merge queue Jan 13, 2025
Merged via the queue into v-next with commit 34e9feb Jan 13, 2025
55 checks passed
@galargh galargh deleted the feat/solidity-test-compilation branch January 13, 2025 11:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:ready This issue is ready to be worked on v-next A Hardhat v3 development task
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants