That's a matter of taste. The subtitle of our book is "Maximize Code Quality and Minimize Software Development Time". I feel that discipline in writing or enhancing testcases for every non-formatting code change does increase the chances that the goal captured in the subtitle of the book will be achieved. Now, technically, you can use Hudson and perform continuous integration and still achieve the subtitle goal even when don't do it before *every* commit. As long as you have some test coverage, you'll still be achieving value because you will be guarding against side-effect regression.
Putting Hudson aside, it is generally very good practice to write tests for each commit. In most places I have worked, potential commits are rejected at the review stage if there is no unit tests to go with it. Only in exceptional circumstances or if the change is minor is the commit approved.
I agree with James and Ed. Writing test cases and using code metrics tools to measure the test coverage is a a good recipe for a successful software life cycle management strategy. While practicing Continuous Integration (CI) running these unit tests and make sure build does not fail is an important principle (See http://www.martinfowler.com/articles/continuousIntegration.html). However, keeping the CI build with in 10 minutes is another important guideline. So, while writing unit tests, keep that in mind and write independent tests for online & offline (example tests involve database connection) consumption. These CI builds must be run in stages to achieve the 10 minutes guidelines. How to achieve this using Hudson-3.x is covered in our book.