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
AssignValueToObject() method etc.
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.
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 is 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.
There are changes-prone situation on
ProcessRequest()whereby a supplier might change their WS endpoint which we requires changes and update on our
Majority of the Result Assigning code is in
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.