In my app, dozens of PCs will be running the visual tier. The business tier will be located on the server, that also contains the database.
Unit testing is really necessary on my visual tier, that basically will contain calls to the business tier? Any particular case?
UI tests are seldom called unit tests because it is really difficult to test a unit of code. In the past we called them integration tests, sanity tests, functional tests or acceptance tests. Essentially they verify the system (not a unit of code) works after it was deployed. But this is debatable based on what you are trying to achieve.
Whether or not to automate the UI tests depends on several factors. The hourly rate of developers is often far more than that of QA. So one has to look at what value automated tests written by a developer provide to the whole organization. The hour a developer spends writing tests may be better spend adding value to the system. However, QA very seldom look at the system from a unit perspective, leaving them at a disadvantage.
However, developers has an intimiate knowledge of the system and therefore can increase quality a great deal if they write tests. Tests act as documentation for other developers and express intent. Finding issues sooner is cheaper and the most compelling motivation for a developer writing tests.
So you need to strike a balance between the two. Developing and maintaining any kind of UI tests are time consuming and complex, especially in distributed environments. UI tests are often unreliable and break easily. You have to consider provisioning the environment, seeding the database and so forth. You also need to consider whether you have enough resources to run automated tests. It also becomes expensive.
You can reduce costs by outsourcing it, or by doing it manually. The latter may be faster to repeat each time than going through the cycle of creating, maintaining, running and diagnosing automated UI tests.
That said, if your UI is stable, it is very advantageous to have a couple of acceptance tests to verify that the system is functional. Look at the 20% features that are used 80% of the time and those features in the UI that if not functional will render the system useless. At least you'll know that the 20% everyone, including your boss or customer, cares about is working before giving to QA or a customer for testing.