Conformance test

Я, как известно, программирую всякие там сервера и сетевые приложения. В этом деле совершенно нельзя пренебрегать обработкой ошибок. и очень ценно построение софта с гарантированно предсказуемым поведением. Последнее время я практикую такой прием.

Пишется класс, содержащий потенциально непредказуемое поведение – например RemoteQueue. Что я делаю:

• рассматриваю все возможные ситуации, которые, по моему мнению, могут возникнуть. Объединяю их в перечислимый тип: (ERROR_SOCKET_ERROR, ERROR_INVALID_ARG, ERROR_NOT_IMPL и т.д.)
• Создаю абстрактный класс AbsQueue, формирующий нужное поведение (или интерфейс). Ни одна функция не может выбросить исключение, все возвращают коды ошибок из вышеуказанного диапазона. Получается контракт класса.
• Пишу Mock (или Fake?) объект – MockQueue, реализующий указанный интерфейс.
• Пишу т.н. ConformanceTest.  Conformance test -  это тест, проверяющий соответствие поведения класса заданной модели. В таких -то ситуациях такой-то метод может вернуть такие-то и такие-то коды, а не другие, метод работает так-то.
• Первым Conformance test проходит Mock – реализация объекта. Вот этот момент вылизывается дочиста. По мере необходимости модифицируется тест, реализация интерфейс, тест. В конце процесса получаем законченный контракт класса.
• Пишем реализацию интерфейса RemoteQueue. RemoteQueue уже опирается на реальные сокеты. Очень строго слежу, чтобы функции не раскручивали исключений, а возвращали правильные коды указанные в контракте класса.
• Подвергаю написанную реализацию conformance test’у.  Дрючу реализацию, пока тест не будет пройден.
• Безбоязненно втыкаю реализацию в вызывающий код.
• Безбоязненно описываю контракт в документации.

Работает отлично.