Refactor Your Code w/o Fear

When you perform a performance boost in your system, many times you need to refactor part of the code, without changing the functionality. When you did not write the code, or it is just too complex, it might be a little bit risky and a very good test plan should be designed in order to assure that logic was not broken while boosting the performance.
When we have Unit Tests in the system it is much simpler (since someone else already done the hard work). Therefore, if your business plan is ambitious, the safe way is starting with a simple system with Unit Tests, and plan for refactoring.
I have been in a short seminar by the industry experts Dror Helper and Gil Zilberfeld from TypeMock that presented several aspects and lessons in TDD, Unit Tests and Mocks. I dropped here some of the lessons that they presented:

1. Make a single assert per function
2. Name the test function FunctionName_TestDescription_ExpectedResult
3. Use the appropriate Assert method in order get most information from the failure (don’t use always IsTrue)
4. Keep tests simple (up to 5-6 lines each)
5. Test (usually) only public methods
6. Code to test, or at least in some cases use re factoring to ease problematic issues (such as pass in date to the function/class when the tested function is based on date.
7. The AAA test structure:
1. Arrange – set up the method/function
2. Act – run the function
3. Assert – call the assert method

Keep Performing,
Moshe Kaplan