I can see a lot of benefits for practicing TDD when developing software applications. But writing Unit Tests can be a lengthy process when done effectively, and it can be difficult justifying the time spent, especially to managers or clients.

So, here are a few tips I’ve learned from my own experience:

• Do not test Getter/Setter properties. For the most part, getting and setting properties is a trivial matter. In the instances where complex logic is implemented in the property, you can usually still get away with not explicitly testing them. Or, test them via another unit test that verifies some business rules.
• Remember good OO Design. If you are not using good OO design, your unit tests will be pretty difficult to write and maintain. Just as small changes in a highly-coupled system can break other parts of the system, the same can be said of your unit tests.
• Do not test for the sake of testing. Although some may argue, I don’t find it necessary to write tests for every class in my project. Unit tests are intended to treat your classes or projects as a black box. The test gives an input, receive an output, and tests it to see if the expected value is equal to the actual value. Therefore, it is possible to write unit tests primarily for controller classes, and test the business classes implicitly.

If you know any other tips for writing effective unit tests, feel free to post a comment and share your experiences.