How We Smoke Test Pull Requests with Git Revert
One weird trick
You’ve been there: you get assigned to review a pull request for a work-in-progress feature you know little about, and you have trouble seeing how it all fits together with the work that’s yet to come. The code looks good, but you’re hesitant to add your stamp of approval and hit the merge button. Even with thorough UI and unit tests, you want to test the new feature and see it in action yourself, just as the author did during development. Rather than making the reviewer follow a complex set of instructions to add code or print statements to verify that the in-progress feature is working, we’ve landed on this one weird trick. Internally, we call it the “git revert trick.”
An example of the git revert trick in action!
How It Works
When a developer is unable to provide clear “How to Test” steps without requiring additional complicated changes, they can now commit and revert the test code that they used to initially smoke test their feature and provide the git command necessary to re-stage the test code in the reviewer’s working copy. The command is git revert -n <revert-test-code-sha>. This reverts the removal of the test code, with -n (short for --no-commit) preventing the revert from being committed, allowing the user to see the working copy changes and easily discard them when they’ve finished testing.
We now frequently make use of this command in our pull request reviews. It removes room for error in the reviewer’s setup process, provides in-context and diff-able code for exercising the changes, and prevents any throwaway test code for in-progress features from ever getting merged.
See it in action in our open source library PinpointKit and let us know what you think of this technique here or on Twitter at @lickability.