TM123 писал(а):Ну мне кажется что последствие любых действий выливается в изменение данных, поэтому корректность ваших действий может быть оценена корректностью изменений данных.
Да. Но корректность изменения данных правилами валидации проверена не может быть. Отгрузка может быть запланирована как на завтра, так и на послезавтра, и обе эти записи являются валидными. Менеджером контрагента может быть как Михаил, так и Сергей, и опять же обе эти записи будут корректные.
То есть правила валидации не помогут проверить корректность алгорима выбора дня отгрузки или же алгоритма выбора менеджера для контрагента.
Если вы с этим не согласны, то приведите пример правил валидации, которые могут оценить корректность изменения данных.
TM123 писал(а):Я так понимаю что вы собираетесь сунуть в процессе тестирования, например, 3 записи, одна, заранее известно какая, должна быть изменена и на выходе проверите что именно она изменилась остальные остались неизменными. Мне кажется что это слишком простой случай, а все сложные случаи из реальной жизни, которые встречались мне, написание теста занимало больше времени чем собственно самого функционала. Кстати в вашем очень простом примере для выполнения действия мне потребуется написать всего 1 команду на SQL, чтобы проверить сделанное тем способом который я предположил, надо несколько десятков строк кода, для проверки результатов работы моей SQL команды средствами SQL потребуется 2 команды или одна но достаточно сложная.
Мой пример не столь и прост. Уровень занятости менеджера может определятся по куче данных. Условия для отбора просроченных документов тоже могут быть весьма нетривиальные.
И да, вы так и не ответили, как бы вы производили разработку данного метода и в частности проверку корректности его работы.
