Unit test coverage of developed code can make sure that functionality won’t change during refactoring of legacy code, new feature development and more.
Although it might help It is not necessary to use Test Driven Development (TDD) all that is needed is to write unit tests before the actual work (i.e before a major bug fix).
Today I found another use of unit tests – code parallelization.
In his blog – Rick Minerich writes on how a developer can parallelize existing code to improve its performance.
Rick uses a methodology called RASP:
- Review: Review code to determine if it is a good candidate for parallelization.
- Anchor: Create a unit test fixture to ensure that the behavior of the to be parallelized code does not change.
- Separate: Ensure that the to be parallelized code has no shared memory constraints.
- Parallelize: Minimally refactor for parallelization while leveraging an existing API to do the heavy lifting.
As you can tell from the steps above an important part of the process is creating unit tests to make sure that the existing functionality won’t change during the process.
Of course users of TDD do not need to write tests because they already have them written as part of the development process.
Another place where unit tests are a major part of creating high quality code.
