Correct Entry Point of Unit Testing

My company just started to practice Unit Testing (MS Test) on an ever-enhancing legacy system.

The system is build with a core functions and developers are developing new features (by adding new Class Library) and integrating to core system through interface such as Overriding or Implements method from the base of core functions. Each of the Class Library we have developed has a standard method ProcessRequest and is a protected override method, that has codes that does processing such as calling to external web service supplier, assigning response object and etc.

However, In each of the individual class library may/may not has utility function methods such as ConvertValue(), AssignValueToObject() method and etc methods.

As what we have raised in a heated argument/discussion, there are people a small group of developers suggest that we only test Utility Function Methods (i.e. ConvertValue(), AssignValueToObject()) whilst ignoring the need to test the code in protected override ProcessRequest() method and suggest that we should only test ProcessRequest () exception handling.

However, a few of the colleagues do support to test even in ProcessRequest() method as well.

My leader has also saying testing ProcessRequest () is "too high level" but I would think that a Unit Test should conduct from the entry point of the new features.

Please advice on the best practice point of unit test entry which is practice in the industry / development culture.

Note:-

• There are changes-prone situation on ProcessRequest () whereby a supplier might change their WS endpoint which we requires changes and update on our ProcessRequest () as well.

• Majority of the Result Assigning code is in ProcessRequest ().

• Has no intention to conduct Unit Test on Legacy code (core system) at the moment as it is too large to be covered. Refactoring codes on legacy codes is not an option.