Поддерживать большие фиктивные данные сложно и нереально. Еще сложнее, когда структура базы данных претерпевает изменения.
Ложь.
Модульное тестирование не требует «больших» фиктивных данных. Требуется достаточно ложных данных для проверки сценариев и ничего более.
Кроме того, по-настоящему ленивые программисты просят специалистов по предметам создавать простые таблицы различных тестовых случаев. Просто простая таблица.
Затем ленивый программист пишет простой скрипт для преобразования строк электронной таблицы в случаи модульного тестирования. Это довольно просто, правда.
Когда продукт развивается, электронные таблицы тестовых случаев обновляются и генерируются новые модульные тесты. Делай это все время. Это действительно работает.
Даже с MVVM и способностью тестировать GUI, для воспроизведения сценария GUI требуется много кода.
Какая? «ВОПРОИЗВЕДЕНИЕ»?
Смысл TDD в том, чтобы спроектировать вещи для тестируемости (Test Drive Development). Если графический интерфейс настолько сложен, то он должен быть переработан, чтобы быть более простым и более тестируемым. Упрощение также означает более быструю, более легкую в обслуживании и более гибкую. Но в основном проще будет означать больше тестируемых.
У меня есть опыт, что TDD работает хорошо, если вы ограничиваете его простой бизнес-логикой. Однако сложную бизнес-логику сложно протестировать, так как количество комбинаций теста (тестового пространства) очень велико.
Это может быть правдой.
Тем не менее, просьба к экспертам в данной области предоставить основные тестовые примеры в простой форме (например, в электронной таблице) действительно помогает.
Таблицы могут стать довольно большими. Но это нормально, так как я использовал простой скрипт на Python, чтобы превратить электронные таблицы в тестовые случаи.
А также. Мне пришлось написать несколько тестов вручную, потому что таблицы были неполными.
Тем не мение. Когда пользователи сообщали об «ошибках», я просто спрашивал, какой контрольный пример в электронной таблице был неправильным.
В этот момент эксперты в данной области либо исправят электронную таблицу, либо добавят примеры для объяснения того, что должно было произойти. Отчеты об ошибках - во многих случаях - могут быть четко определены как проблемы тестового примера. Действительно, исходя из моего опыта, определение ошибки как неработающего тестового примера значительно упрощает обсуждение.
Вместо того, чтобы слушать экспертов, пытающихся объяснить сверхсложный бизнес-процесс, эксперты должны привести конкретные примеры этого процесса.
TDD требует, чтобы требования были на 100% правильными. В таких случаях можно ожидать, что конфликтующие требования будут учтены при создании тестов. Но проблема в том, что это не так в сложном сценарии.
Неиспользование TDD требует, чтобы требования были на 100% правильными. Некоторые утверждают, что TDD может терпеть неполные и изменяющиеся требования, когда подход без TDD не может работать с неполными требованиями.
Если вы не используете TDD, противоречие обнаруживается на поздней стадии реализации.
Если вы используете TDD, противоречие обнаруживается ранее, когда код проходит некоторые тесты и не проходит другие тесты. Действительно, TDD дает вам доказательство противоречия в начале процесса, задолго до реализации (и аргументы во время приемочного тестирования пользователя).
У вас есть код, который проходит одни тесты, а другие не проходит. Вы смотрите только на эти тесты, и вы обнаружите противоречие. Это работает очень, очень хорошо на практике, потому что теперь пользователям приходится спорить о противоречии и приводить последовательные, конкретные примеры желаемого поведения.