@whirlwind а почему?
Что тут неправильно?
1) Если этот тест свалится в сете из 1000 тестов по названию теста можно понять в каком методе проблема, куда смотреть?
Я бы назвал так
testSave_IfCondition
testSave_IfNotCondition
2) Есть два типа тестирования: тестирование состояния и тестирование поведения. Здесь тестирование поведения - то есть тест взаимодействия со смежными интерфейсами. Что говорит этот тест? Тест говорит: запиши что нибудь. Если не смотреть в код класса, то из теста непонятно что конкретно юнит должен делать. Условие теста нечеткое - тест теряет характер спецификации и документации - тест не очень хороший.
3) Если возникают проблема при написании теста, то проблема не в тесте, а в дизайне. Используй декоратор поверх основного стораджа и сделай в нем кэш. И первоначальная проблема просто исчезнет.
Всегда - тяжело сформулировать тест/тест большой/много фикстуры/непонятный - проблема в дизайне.
PS. Думал, думал что мне здесь не нравится. Вообще здесь смешан сервисный слой и предметная область. Самое очевидное и правильное тут имхо разделить ответственности. Атрибуты инкапсулировать в VO - этим редуцируем сложность тестирования условия. А сервисный слой разбирает VO и сохраняет. Ну а кеш поверх стораджа прозрачно для потребителей - это классика.