Can you elaborate a bit further? I'm trying to make my design/test suite more robust at the moment and it would be good to hear from others who have been through the same process.
Of course all of the parts of the main process that had external dependencies like api calls and database calls were injected. While other people were writing the code, I was constantly changing the dependency chain on the core routines they were dependent on, I was changing the wheels on a moving train.
This wasn't an issue with the actual program because we were using a DI Framework, all of the dependencies were being wired up automatically at the composition root (http://blog.ploeh.dk/2011/07/28/CompositionRoot/).
But Mocking out everything was painful and if the dependencies changed anywhere within the framework, the tests broke - they wouldn't compile. On top of that, while you can add optional arguments to a method and it won't break preexisting code, it will break your Mock setup (long story).
Just like it is a well known anti pattern to use DI as a service locator (http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Patte...), so is the overuse of Mocks.
Moving to a more functional model means we have a service class where you still inject your dependencies but our classes that have business logic are completely functional - they take in data and return data. The service class is responsible for the orchestration of getting the data, processing the data, and sending the data.
The mapping classes also expose events that the service class can subscribe to if it needs to do something during the processing of each transaction like logging.
Now the only classes we need to unit test, have no dependencies and no mocking. (https://medium.com/javascript-scene/mocking-is-a-code-smell-...)
But we also found that our biggest issues aren't having regressions around our individual programs, but around integrations - thus the need to build up our automated integration testing environment.
1. We always commit to the master branch where automated unit tests use to run. We threw out all of our unit tests because of some design mistakes that I made as the first time Dev lead. We were too dependent on brittle Mock based tests when we should have used a more functional (no dependency/ no side effect business classes), based approached we started using.
2. We have an Integration environment setup where everything is deployed to whose purpose was to do automated integration tests but haven't gotten around to it yet.
3. Since every push goes to Dev but we don't want every push to go to QA. The devs have to do a post deployment approval before it gets to the QA queue.
4. Qa has to do a predeploymebt approval when they are ready to test a build. After they test, they do a post deployment approval.
5. Since we have a mandate thT each developer is responsible for getting their own code to production. They have to work with the product owner and coordinate when it should be released to UAT. Then the developer does a preapprovsl for it to go to UAT.
6. Once it is approved by the product owner and we get change control approved. I as the dev lead and my manager both have to do a post approval.
7. Then the developer does a preapprovsl and it goes to production.
Yes it sounds convoluted but people above my pay grade make those decisions (once the avalanche has started the pebbles don't get to vote). But, appprovals are done on a simple Visual Studio Team Services Web page accessible from anywhere and once done, deployments are automatic.
We also don't explicitly version code. We tag each built executable with the Git commit hash and that hash is logged as a property with each log statement. We use Serilog for structured logging.
We can rollback just by redeploying a previous release. If we need to make a change to a previous "version". We just branch based on the logged git hash.