Я не делаю много новых разработок прямо сейчас, но много рефакторинг старых подсистем C #, чьи первоначальные требования больше не поддерживают новые, и я добавлю неожиданные требования. Я также сейчас использую Moh Rhino и юнит-тесты, где это возможно (vs 2008).
Дилемма для меня заключается в том, что для того, чтобы сделать методы тестируемыми и поддающимися проверке, мне нужно определить четкие «контракты» с использованием интерфейсов. Однако, если я сделаю это, большая часть глобальных данных, которые используют многие классы, превратится в данные бродяги, передаваемые из метода в метод, пока не дойдут до предполагаемого пользователя; это выглядит некрасиво и противоречит моим чувствам, но ... может быть осмеяно. Создание смешанного класса мешков со множеством статических глобальных свойств - более привлекательный вариант, но его нельзя проверить на Rhino. Есть ли середина между двумя? Тестируемый, но не слишком трамплинный? Выкройка что ли?
Вы также должны понимать, что эти приложения работают на собственной корпоративной платформе, поэтому существует множество вспомогательных классов и служб, которые создаются один раз для каждого приложения, а затем используются во всем приложении, например, средство доступа к базе данных. вспомогательный класс. Другой пример - использование файлов конфигурации, которые считываются один раз и используются по всему приложению различными способами по разным причинам.
Ваши мысли оценены.