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

Suggested content rewrite #14498

Closed
YakshitAgarwal opened this issue Dec 13, 2024 · 13 comments
Closed

Suggested content rewrite #14498

YakshitAgarwal opened this issue Dec 13, 2024 · 13 comments
Assignees
Labels
awaiting PR Issue is ready for a pull request good first issue Good item to try if you're new to contributing

Comments

@YakshitAgarwal
Copy link
Contributor

The following content seems to be partially correct and could use some clarification. The path to the content is:
public/content/developers/docs/smart-contracts/testing
The content is:
"Tests should have good code coverage, otherwise you may get "false negatives" which happen a contract passes all tests, but vulnerabilities still exist in the code."
The rewrite for the above text should go like:
"Tests should have good code coverage to minimize the risk of untested vulnerabilities. Without sufficient coverage, you might falsely assume your contract is secure because all tests pass, while vulnerabilities still exist in untested code paths."
Explanation:

  1. Code Coverage and "False Negatives":
    Code coverage measures how much of your code is executed during testing. High code coverage ensures that most (or all) lines of your code have been tested at least once.
    Low code coverage can indeed lead to untested portions of code where vulnerabilities or bugs may reside. This might create a false sense of security, as your tests pass without actually verifying the behavior of the untested code.

  2. Misinterpretation of "False Negatives":
    Technically, a false negative in testing occurs when the test fails to detect an issue that exists. In the context of your statement, what you're describing is not a "false negative" but rather uncovered vulnerabilities or bugs due to inadequate test coverage.

@github-actions github-actions bot added the needs triage 📥 This issue needs triaged before being worked on label Dec 13, 2024
@konopkja konopkja added awaiting PR Issue is ready for a pull request good first issue Good item to try if you're new to contributing and removed needs triage 📥 This issue needs triaged before being worked on awaiting PR Issue is ready for a pull request labels Dec 13, 2024
@konopkja
Copy link
Contributor

"Misinterpretation of "False Negatives":
Technically, a false negative in testing occurs when the test fails to detect an issue that exists. In the context of your statement, what you're describing is not a "false negative" but rather uncovered vulnerabilities or bugs due to inadequate test coverage."

read as AI generated text, needs edits before PR for reader.

@YakshitAgarwal
Copy link
Contributor Author

I am a little confused on what you are trying to tell here. Should I change the rewrite of the content or the explanation?

@konopkja
Copy link
Contributor

aah sorry my bad, i thought the two points are part of the content that should be added, but now i see its just more clarification.

@konopkja
Copy link
Contributor

konopkja commented Dec 13, 2024

so the new text is just this right?

"Tests should have good code coverage to minimize the risk of untested vulnerabilities. Without sufficient coverage, you might falsely assume your contract is secure because all tests pass, while vulnerabilities still exist in untested code paths."

if so i think it looks good and anyone can make PR with the edit.

@YakshitAgarwal
Copy link
Contributor Author

Yes

@konopkja konopkja added the awaiting PR Issue is ready for a pull request label Dec 13, 2024
@konopkja
Copy link
Contributor

Okay, this needs a contributor to submit PR with the edit now

@YakshitAgarwal
Copy link
Contributor Author

Thanks for the help!

@isabelladebrito
Copy link

isabelladebrito commented Dec 13, 2024

Hi @YakshitAgarwal and @konopkja! Is this PR related to the issue? #14499

If yes, @konopkja can you please assign @YakshitAgarwal to this issue - so it prevents someone else to work on it? Thanks!

@YakshitAgarwal
Copy link
Contributor Author

Yes it is.

@YakshitAgarwal
Copy link
Contributor Author

Hi @isabelladebrito, actually this is my first time contributing. I wanted to ask, does the acceptance of PR actually take long interval or is it like less than a day?

@konopkja
Copy link
Contributor

Hi @isabelladebrito, actually this is my first time contributing. I wanted to ask, does the acceptance of PR actually take long interval or is it like less than a day?

Welcome aboard! Merging PRs can take a while depending on the current commitment situation. Right now the core team is finishing big release and it may take extra time before reviewing and merging your PR.

Sorry for inconvenience, but I hope you can understand. Do not worry it will be reviewed and not forgotten :)

@YakshitAgarwal
Copy link
Contributor Author

Sure, its no biggie!

@YakshitAgarwal
Copy link
Contributor Author

Hey @konopkja, you can close this issue now. The PR has been mergered. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting PR Issue is ready for a pull request good first issue Good item to try if you're new to contributing
Projects
None yet
Development

No branches or pull requests

3 participants