Our company creates financial software that integrates into a banking system backend. We're running into a lot of problems making changes to it without seemingly impacting another customer or another banking backend system.
The company goal is to push for one product having seamless integration among any and all systems. But practical experience is telling me this is not possible nor sustainable after n number of customers implemented.
The backend is not owned by us, but it is absolutely vital in order for our product to function. We have various ways of communicating with the backend systems (Sockets, Named Pipes, Web Services, WCF Service, File In File Out) and the data format, and it's contents is variable. This means that we also need to have dynamic hiding/unhiding of ui fields and forms that don't apply to whatever banking system is being used.
The biggest problems we are facing is maintenance - it's impossible to make a change without seemingly impacting another client several months down the line.
I've been tasked with refactoring some of the business layer methods so that we can implement a new customer (with new banking API calls that were never done before). Now I decided i would try to write integration tests as I'm doing this to have some confidence i dont break something in the process of refactoring, but the system was not designed to be unit tested at all. The only tests I can make that work involve creating real IPC objects that mimic a backend system where I can check that the receive and response messages are in the correct format with the correct data, but these are so fragile and need lots of dependencies to work (ie. proper application config, multiple databases).
I'm afraid after just writing 20 test cases that this is not scalable nor maintainable as the code changes. The tests feel too fragile. What should I do? I've been trying to push for rewriting the business layer for a long time now, but people are scared of breaking what already works.
