Unit tests are probably one of the most important inventions in software engineering since I started programming Go. In itself the concept is simplicity itself. And the rewards can be great. The price to be paid is the discipline to write them. Good unit-tests are not always easy to write, but at least it should always be attempted. I have yet to write a unit-test that didn't pay back the effort of writing it by the time saved at a later stage. I'm not in favour of writing a unit-test for every simple class, but at least I think it should be tried to write one for every non-trivial class. On top of that a unit-test should be written for every bug found.
Fortunately we have JUnit to make life easier. Moreover Eclipse has JUnit support built in to make life easier yet. When you open a class that is a JUnit test-case, you can simply choose 'Run as... -> JUnit Test' from one of the (context-) menus. Simple as that. Running all unit-tests in the project is just as easy. From the project top-level choose 'Run...' and right-click on JUnit and choose 'New'. It will add a run configuration for running all unit-tests in the project. Clicking 'Run' does the rest.
In the old days there used to be a phrase "Don't break the build." That meant you were not allowed to commit any source-code to the repository before you made sure everything still compiled. Regular (nightly) compile-runs would check if all commited source would compile and whenever a compile-error occurred the offender would be really frowned upon.
Nowadays we go one step further. We say "Don't break the unit-tests.". With a similar regularity all unit-tests in the repository will be executed, and whenever one doesn't pass the test, the offender... well you get the picture.
I'll use a simple rule for unit-tests. Whenever a unit-test is written, it resides in a package directly descending from the place where the class to be tested resides. For example: the unit-test that tests the class tesuji.games.go.common.BasicGoMoveAdministration resides in te package tesuji.games.go.common.test. Whenever a test is made that needs to test the collaboration of two classes, then the 'test' package is created from the highest descendent in the source-tree that includes all collaborating classes.
If you came here from the GoGui page you were maybe expecting an example, so here it is. The first unit-test written for this project is tesuji.games.go.common.test.MoveAdministrationUnitTest. It's all not too complicated, I wrote a simple test for capturing a single stone, one for capturing an empty triangle and one for testing ko. After writing what seemed like such straightforward test-cases,, I ran the unit-test in Eclipse. And lo and behold, it failed. There turned out to be a bug on the isLegalMove method and I made a mistake in the method _hasLiberty by recursively calling hasLiberty instead of _hasLiberty which occasionally causes an endless loop. So you see, the effort of writing these tests already paid me back substantial time that would otherwise be needed identifying these bugs through other means.