Вопрос: Как придти к автоматическому тестированию?

Лучший ответ:
К сожалению, про тестирование и 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() (это стоит делать в любом случае) и собирать жалобы пользователей на баги, но это не всегда возможно, одно дело бесплатный сервис вроде фейсбука, который сломался и ничего страшного, другое дело, если из-за ошибки нарушатся какие-нибудь многомиллионные бизнес-процессы в крупной корпорации или счета в банке.

Худший ответ:
ИМХО, проще руками его создать и проверить — пришло задание куда надо или нет. Что тут автоматизировать?..Вот это неверная мысль. Представьте, что проектов таких у вас в компании не один, а 100. Вы (или тестировщик) будете каждый день залезать и проверять, пришло оно куда надо или нет? Вряд ли. А тест будет. В этом соль.
С чего начать — посмотрите, какие у вас есть модули, какие операции они выполняют — эти операции и проверяйте. Разумеется, модули должны быть слабо связными, такими чтобы можно было их протестировать (если мы, конечно, говорим тут о модульном тестировании).
теги доставили