> 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.
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.
We were using a dependency injection framework to do constructor injection. All of our apps basically have one job, to either take external data from somewhere and map it to a common model and send it to Mongo through an API, or send it somewhere from the common model to an external source (a Master Data Model system).
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).
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.
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.
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.