Since I developed a few symfony plugins I get bug reports. People use these plugins (people in the community or colleagues at work) and find issues.

Usually the answer is a misconfiguration but sometimes of course they found one of the bugs I involuntarily put in the code.

In these cases I have to get down at the code level and try to fix it. This is how I usually do it.

1. Setup a fresh symfony installation and vHost

I don’t want to work in a existing application and I don’t want to risk side effects from previous experiments so I create a fresh symfony project with all stuff I will need to reproduce this bug like an application, a model, other plugins, whatever.

2. Clone the plugin from github and create a local git branch

I then clone my own plugin from its GitHub repository and get it working. I then create a local branch that I can commit to all the changes I will do to find and fix the bug.

3. Reproduce the error

I then try to reproduce the error. This might be the hardest task of all as some information is always missing. But also this is quite often the point where I stop the bug hunt and skip to the end as I found the bug to be a configuration mistake again.

4. Add debug code to find the location where the expected behaviour breaks

This might be old school but I do this anyway. Usually I just var_dump() the parameters that go into the methods that did not behave. If they are correct the bug is likely in the algorithm of that method. If they are not correct then I have to move up and investigate why.

5. Write a unit test for that particular location

In the end I will have found a spot where a specific input to a method will produce a wrong output. I then write a unit test that tests with these input values and checks for the correct result.

6. Fix the bug

Most of the times this process takes a long time and in the end will result in only one or two lines of code that is changed. Yet sometimes This might be an error in the architecture and I have to redesign parts of my plugin. But at the end of the process all unit tests must pass and the bug is fixed.

7. Refactor your code and remove the debug code

Clean up after yourself! Remove any commented code, debug outputs, debug logs and add doc blocks if feasible.

8. Extend the documentation if applicable

If the bug fix affects the usage of the plugin I write some more documentation that informs the user of the changed behaviour. I also write a changelog.

9. Merge the branch to the master

When the bug hunting branch is no longer needed I merge it back to the master branch and remove it again from my local repository.

10. Push to GitHub and release a new Version

I then push the updated master back to GitHub, set a git tag and commit that tag to the official symfony SVN or if it’s an internal plugin to the SVN of my team.

Afterwards I can remove the whole project and vHost again and leave as if nothing ever happened.

best practice · Debugging · Plugin · plugins · Refactoring · symfony · Unit Tests

<< First stable release of gjPositionsPlugin for easy page composition with symfony and doctrine

My idea of a symfony form widget for the doctrine data type Array >>