http://corgibytes.com/blog/2016/11/01/throwaway-code
blog-post-throwaway-code#second-failing-test-at-lower-level-in-pyramid1 2 3 I eventually find the bug, and I'm able to identify the change that needs to be made to fix it. Most devs I've worked with over the years stop there. They have a failing test and a commit that fixes it. Job done. Time to move on. I think this is a missed opportunity. It's hard for me to imagine a bug that can't also be reproduced via a unit test or an integration test. What I prefer to do is to add a second failing test at a lower level on the pyramid, and then make sure that the "fix" I'm applying fixes both the higher-level acceptance test and the lower-level test. blog-post-throwaway-code#second-failing-test-at-lower-level-in-pyramid1 2 3
blog-post-throwaway-code#delete-temporary-acceptence-test-covered-elsewhere1 I then delete the acceptance test from the project. I don't need it anymore. It was a troubleshooting tool, and it did its job. I have another lower-level test which covers the specific change I made. blog-post-throwaway-code#delete-temporary-acceptence-test-covered-elsewhere1
blog-post-throwaway-code#add-and-then-remove-test-no-squash1 I like to make sure that the acceptance test is committed to source control after I have it failing. Then, I create a separate commit later on to delete it. I don't usually squash my commits. This ensures that I'll be able to find that specific acceptance test in the source control history if I ever happen to need it again. But anyone who looks at the combined diff for the resulting pull request won't see that the acceptance test was ever there. And, in that way, I think that these temporary acceptance tests I create are perfect analogues for the structure I captured in the picture above. blog-post-throwaway-code#add-and-then-remove-test-no-squash1