К сожалению, про тестирование и TDD много пишут всякие теоретики и любители написать 3 абстрактных класса ради вычисления факториала. Особенно плохо совместим TDD с активным рефакторингом.
Модульное тестирование не имеет особого смысла для модулей с примитивной логикой. Модульное тестирование во-первых, применяют, к модулям с математикой/хитрой внутренней логикой, во-вторых, проверять результат надо альтернативным способом.
Пример правильного модульного тестирования:
Например, есть функция решения квадратного. ур: x1, x2 = solveQuadEq(a, b, c );
Пишем к ней тест:
a, b, с = 1, 2, 3;
x1, x2 = solveQuadEq(a, b, c);
test::assertFloatEqual(a * x1 * x1 + b * x1 + c);
test::assertFloatEqual(a * x2 * x2 + b * x2 + c);
(Заметьте, результат проверяется подстановкой корней в уравнение назад, а не решением уравнения). И так несколько раз с разными a, b,c.
Имеет смысл применять модульное тестирование, например, для проверки модуля извлечения номеров телефонов из текста или модуля OCR.
Тестировать «тонкие» и «глупые» контроллеры и вьюхи — ровно столько же смысла, сколько тестировать работу функции printf(). То есть никакого.
Для вашей же задачи больше подойдет функциональное тестирование, то есть тестирование отдельных процессов и сценариев работы, например: создать документ, добавить файл, отредактировать документ, удалить документ, при этом проверять отсутствие зависаний (таймаутов), ошибок и предупреждений на клиенте и на сервере. Опционально (но не обязательно) можно проверять например, что документов стало на 1 больше, что в хранилище появился и исчез файл, что в отчете о документообороте добавились строчки, что пользователю отправлено письмо, в котором содержится такой-то номер документа или такое-то ключевое слово.
Не знаю, есть ли средство для организации подобного тестирования вашего ПО. Возможно, что такого нет в природе. Даже браузерные средства тестирования веб-приложений типа Selenium весьма неудобны и слаборазвиты.
Но проверять результат не так важно, так как уже одной проверки, что все кнопочки в вашем приложении нажимаются и не генерируют ошибок и таймаутов, уже более чем достаточно (с большой вероятностью это означает, чт программа исправна). Этот тест полезен, например, для веб-приложений, так как когда программисты активно рефакторят код, они могут сломать какую-нибудь яваскриптовую кнопочку в забытом всеми диалоге, а никто и не заметит. Представьте, сколько времени тестеров отнимает без автоматизации обход всех страниц и нажатие всех кнопок.
Также, если это вам кажется сложным, можно тестировать продукт на пользователях: ввести максимальное логгирование всех ошибок и предупреждений, наставить всюду в коде assert() (это стоит делать в любом случае) и собирать жалобы пользователей на баги, но это не всегда возможно, одно дело бесплатный сервис вроде фейсбука, который сломался и ничего страшного, другое дело, если из-за ошибки нарушатся какие-нибудь многомиллионные бизнес-процессы в крупной корпорации или счета в банке.
Простой
Простой
Простой
Простой
