If you can set contributors up for success in your project by providing good test coverage and existing suggested best practices, it is worthwhile to do so. With this, adding test cases for a PR’s affected experiences is a reasonable ask for contributors. Ask them to provide first-hand recording of the working experiences for the happy path and sad path, as well as unit/integration/E2E tests to cover the new work.
It does not require you to pull the code down to try it in order to approve it, because you trust your test infra, and it encourages contribution from others for the same reason, because they trust your test infra.
I'm not saying to not trust the tests. The tests might be 100% correct.
I'm trying to simply advocate for knowing what the code's actual behaviors are when reviewing code. The number of times a behavior is different than the requirements written but the tests passed are enough for me to want to check on important code changes.
Is that every code change? Probably not. I can see how that wasn't clear in my article though in that regard so thanks for brining it up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you can set contributors up for success in your project by providing good test coverage and existing suggested best practices, it is worthwhile to do so. With this, adding test cases for a PR’s affected experiences is a reasonable ask for contributors. Ask them to provide first-hand recording of the working experiences for the happy path and sad path, as well as unit/integration/E2E tests to cover the new work.
It does not require you to pull the code down to try it in order to approve it, because you trust your test infra, and it encourages contribution from others for the same reason, because they trust your test infra.
Hey Brandon! Thanks for reading.
I'm not saying to not trust the tests. The tests might be 100% correct.
I'm trying to simply advocate for knowing what the code's actual behaviors are when reviewing code. The number of times a behavior is different than the requirements written but the tests passed are enough for me to want to check on important code changes.
Is that every code change? Probably not. I can see how that wasn't clear in my article though in that regard so thanks for brining it up.