| The easiest place to start testing is likely to be in the code you are touching now. It is fresh in your head, you know what it does. Write a test for that, it shouldn't take you too long. If you are doing a targeted bugfix (i.e. not with a shotgun) you already know the test you have to write: a test for the bug. Try to first write the test and then make it pass (also know as fixing the bug), so you know that the test will spot a regression on future runs. If you are working on a new feature, try to isolate the core logic of the feature and test that. If you can, test it in isolation from the rest of the system and integrate it after you have achieved some semblance of correctness. If your code base has parts that you only touch rarely and you know (or hope) are reasonably solid, leave them for later. The highest risk for breakage tends to be near the spots with the most code churn, so put your tests there. Also remember that tests are code and they must be maintained as you would maintain the rest of your code. Writing tests for implementation details that have no real impact on program correctness won't yield you much value when weighted against the cost of their maintenance. If you are after the most "value per test" think about it this way: The most valuable test you can write today is the one that will catch breakage tomorrow. So, think of the code most likely to break (or the one that will hurt you the most when it breaks) and test that. The first time that test unexpectedly goes red, it will have paid for itself. |