Transforming Bugs into Bulletproof Code: A Step-by-Step Guide to Enhancing Your Development Workflow

Transforming Bugs into Bulletproof Code: A Step-by-Step Guide to Enhancing Your Development Workflow

(ChatGPT wrote the title and these first 4 paragraphs based on my prompt you can see at the end, which contained the sequence of events and actions)


In the ever-evolving landscape of software development, encountering bugs is as inevitable as the sunrise. However, the way these bugs are addressed can significantly impact the efficiency, reliability, and overall success of the development process. Traditional approaches often involve a direct dive into debugging and immediate fixes. While this might offer a quick resolution, it often overlooks the underlying systemic issues and potential for recurring errors. It's time to rethink our strategy, transforming bug handling from a reactive task into a proactive step towards building more resilient applications.

This guide introduces a refined development workflow that not only addresses bugs as they arise but also fortifies your code against future issues. By integrating a systematic approach to identifying, documenting, and resolving bugs, developers can enhance code quality and project robustness. This workflow pivots on the principle of test-driven development (TDD), but with a twist—focusing on turning bug discovery into an opportunity for improvement rather than a mere obstacle to overcome. Here's a closer look at the steps involved in this transformative workflow:

  • When hitting on a bug, pause the urge to fix it immediately.
  • Don't start fixing it; instead, take a moment to understand the bug's impact.
  • Write a passing test(s) that replicates the bug. This creates a 'bug test' that does not break the Continuous Integration (CI) pipeline.
  • Then look for and do the fix. This is where the actual debugging happens, but only after ensuring that the bug is fully understood and can be replicated through tests.
  • Change the test to now be a regression test. The 'bug test' transitions into a 'regression test', still ensuring it doesn't break the CI pipeline.
  • Run all tests to confirm there are no side effects from the fix.
  • If side effects on other tests, start again. This time, the focus shifts to the bug found as a side effect of the initial fix.
  • Rinse and repeat. This iterative process ensures all potential issues are addressed.
  • Once all tests pass, push to CI pipeline. This is a crucial verification step before merging changes.
  • All tests should pass in CI pipeline to confirm the robustness of the fix.
  • Merge into dev branch. This final step integrates the bug-free code into the main development branch, enhancing the overall code quality.

By embracing this workflow, developers not only resolve current bugs but also preemptively mitigate future issues, leading to a more stable and reliable codebase. This approach encourages a deeper understanding of the bug's root causes, promoting a culture of continuous improvement and learning within the development team. The shift from a fix-it-now mentality to a test-first philosophy might seem daunting at first, but the long-term benefits in code quality and team productivity are undeniable. Through this guide, we aim to empower developers to transform bugs into opportunities for strengthening their code, making their development workflow not just efficient, but bulletproof.


...me again ....

Real-world example of this pattern in action

Here is the location where the bug appeared (i..e when I added that @trace_calls() method decorator to the test)

Zooming in on the error details that showed the exception and source of the bug

First step was to write the test that replicates the bug

Since we can, let's see if ChatGPT spots any issues with it (or spelling mistakes in comments)

Here is another test that replicates better the original method that triggered the bug

Once we have these two tests, in there, let's make sure all is good with the tests (from the https://github.com/owasp-sbot/OSBot-Utils repo)

After applying the first fix, and running all tests, there were a number of tests that failed, because we introduced a new bug

So we write a new test for that bug

As we fix the the bugs we convert (as described in the workflow above) those 'bug tests' into 'regression tests' (note the FIXED comments and the changed test title)

Here are the 'regression tests' for the 'bug tests' shown before

Now that we have the fixes in place, we can add back the @trace_calls decorator, which is now working as expected

A nice visual way to confirm that all tests passed in GitHub Actions, is the fact that a new commit has been created in GH that increases the tag with the current version

and just to fully confirm that all is good in GitHub actions here are the tests passing (and the action that was triggered on tests successful that executes the workflow to increase the tag and update the version file in the repo)

This is a very powerful workflow, which not only is a very effective way to fix bugs, it leaves behind a series of regression tests (which I've found in the past to be VERY powerful, since sometimes those test are the ones that catch subtle new bugs)

This workflow also allow the separation of the timings of 'finding and fixing the bug'. I.e. we could have these tests written in a sprint, and the fix only done in a future sprint

Further reading

For more on this , see this slide deck Start with passing tests (tdd for bugs) from the presentation I delivered on this topic back in 2016

Original prompt and DALL-E image

This is the full image created by ChatGPT's DALL-E, which is actually quite cool (included here since LinkedIn is truncating this image when used in on the top of this article)

Here is the extra prompt added to ask for the title and 4 paragraphs (3 + bullet points) you can see at the start of this article


要查看或添加评论,请登录

社区洞察

其他会员也浏览了