CI/CD: Lack of Automated Enforcement for Mandatory Unit Test Coverage on Newly Introduced Solidity Smart Contracts

[aniket866]

Feature and its Use Cases

Summary

Newly added Solidity contract changes/new file are not automatically checked for corresponding unit test files. This creates a quality and security gap in the current review configuration.

---

Problem

When a new contract file (*.sol) is added to the repository:

• There is no validation ensuring a matching test file exists.
• The pull request can be merged without automated test coverage.
• Critical contract logic may go untested.

Given the security-sensitive nature of smart contracts, this is a high-risk process weakness.

---

Current Behavior

• Solidity contracts are reviewed for security, gas optimization, and best practices.
• Solidity test files are reviewed if present.

However:

• There is no rule requiring a test file when a new contract file is introduced.
• No warning or error is triggered if tests are missing.

---

Expected Behavior

When a new Solidity contract file is added:

1. The system should detect the addition of the contract file.

2. It should verify that a corresponding test file (e.g., ContractName.test.sol) exists.

3. If no matching test file is found, the review system should:

   • Raise a warning (minimum), or
   • Block the merge (recommended for production repositories).

---

Impact

Without this enforcement:

• Security vulnerabilities may go undetected.
• Business logic may not be validated.
• Refactors may introduce silent regressions.
• Deployment risk increases significantly.

---

Proposed Enhancement

Implement an automated rule that:

• Detects newly added *.sol contract files (excluding *.test.sol).
• Requires a corresponding unit test file.
• Fails or warns the pull request if the test file is missing.

---

Priority

High — especially for repositories containing production smart contracts.

Additional Context

@kpj2006 Please share your view on this?
feel free to assign

Code of Conduct

• I have joined the Discord server and will post updates there
• I have searched existing issues to avoid duplicates

[kpj2006]

Great!! this is good issue.

i am not sure how you are going to implement this.

what i getting from it is this you probably searching for .sol but what if someone just make blank file with this name
and what about other language like we have contracts in rust ,move and maybe in future we have test in python and js also in our org.

another point, I am not sure if this concern is valid or not, since maintainer prefer small pr but adding tests due to this label may create additional overhead for them and also in this case on which pr you gonna trigger the workflow. however, maybe it can helps them also, until contributor not add test, they not going to merge it.

idk, i mixed the feeling but consider edges before proposing any idea.

[aniket866]

Great!! this is good issue.

i am not sure how you are going to implement this.

what i getting from it is this you probably searching for test.sol but what if someone just make blank file with this name and what about other language like we have contracts in rust ,move and maybe in future we have test in python and js also in our org.

another point, I am not sure if this concern is valid or not, since maintainer prefer small pr but adding tests due to this label may create additional overhead for them and also in this case on which pr you gonna trigger the workflow. however, maybe it can helps them also, until contributor not add test, they not going to merge it.

idk, i mixed the feeling but consider edges before proposing any idea.

see for other projects (which don't have test) this action will not get triggered and about testing it first detects if the coding change is breaking or major then it enforces to add test that should be and maintainer do not merges such prs which do not include respective tests , so this is all a good idea to implement this

[kpj2006]

i didn't get the point

see for other projects (which don't have test) this action will not get triggered

ig the repo not containing test is your main target or maybe you wanna say not having .sol, .move, .rs are going to ignore.

and about testing it first detects if the coding change is breaking or major
then it enforces to add test that should be and maintainer do not merges such prs which do not include respective tests , so this is all a good idea to implement this

Sorry, I’m not fully understanding this.

can you explain with a little example??

[aniket866]

i didn't get the point

see for other projects (which don't have test) this action will not get triggered

ig the repo not containing test is your main target or maybe you wanna say not having .sol, .move, .rs are going to ignore.

and about testing it first detects if the coding change is breaking or major
then it enforces to add test that should be and maintainer do not merges such prs which do not include respective tests , so this is all a good idea to implement this

Sorry, I’m not fully understanding this.

can you explain with a little example??

see we will configure this as to detect changes in files like .sol, .rs etc which requires tests , other files changes would not require test so will be skipped, that's all

[kpj2006]

see we will configure this as to detect changes in files like .sol, .rs etc which requires tests , other files changes would not require test so will be skipped, that's all

ok let's take an case if any changes in these file, label applied and contributor add the test but after the merge still the label of test-not-added stills remains, which is ig not a good practices.(in this also consider test cases written in py or js also if possible)

can you enhance this last step??

see this also:

what if someone just make blank file with this name