Создать объект в тестах с кастомной датой в CreatedDate

Появилась такая задача -

протестировать кусок кода, в котором выборка из базы "старых" Contact (созданных скажем день назад). Выборка ведется по CreatedDate < DateTime.now().addDays(-1)

Как мне в тестах воссоздать данную ситуацию. Заполнение поля CreatedDate невозможно - получается ошибка "Field is not writeable: Contact.CreatedDate"

Не думаю что я первый столкнулся с такой задачей.

Вот тут нашел пару примеров как решать это проблему

Unit testing code which has logic around the CreatedDate

Но хотелось бы услышать ваше мнение.

Dmitry Shnyrev

Появилась такая задача - 
протестировать кусок кода, в котором выборка из базы "старых" Contact (созданных скажем день назад). Выборка ведется по [b]CreatedDate < DateTime.now().addDays(-1)[/b]

[b]Как мне в тестах воссоздать данную ситуацию. Заполнение поля CreatedDate невозможно - получается ошибка "Field is not writeable: Contact.CreatedDate"[/b]

Не думаю что я первый столкнулся с такой задачей.

Вот тут нашел пару примеров как решать это проблему
[url=http://salesforce.stackexchange.com/questions/62/unit-testing-code-which-has-logic-around-the-createddate]Unit testing code which has logic around the CreatedDate[/url]

Но хотелось бы услышать ваше мнение.

Вот нашел даже статью на эту тему от наших белорусских коллег
EDIT CREATED DATE FIELD IN SALESFORCE
Но по ходу все эти костыли не позволяют записать все это в базу, а посему все это плохо подходит для проверки моего кода (без дополнительных костылей для тестов)

Dmitry Shnyrev

Вот нашел даже статью на эту тему от наших белорусских коллег
[url=http://cloudcatamaran.com/2014/01/edit-created-date-field-in-salesforce/]EDIT CREATED DATE FIELD IN SALESFORCE[/url]
Но по ходу все эти костыли не позволяют записать все это в базу, а посему все это плохо подходит для проверки моего кода (без дополнительных костылей для тестов)

Быть может стоит метод переделать, избавиться в нём от зависимости, передав дату в аргумент.

К примеру, вот есть метод:

public static List<Contact> getOldContacts(){
     DateTime dateTime = DateTime.now().addDays(-1);
     return [SELECT id FROM Contact WHERE CreatedDate < : dateTime];
}

В тестах этот метод ничего не вернёт, но можно ведь сделать так:

public static List<Contact> getOldContacts(DateTime dateTime){
     return [SELECT id FROM Contact WHERE CreatedDate < : dateTime];
}

Куда более универсальный метод, не так ли?)

Dmitry Lisovsky

Быть может стоит метод переделать, избавиться в нём от зависимости, передав дату в аргумент.

К примеру, вот есть метод:

[code]
public static List<Contact> getOldContacts(){
     DateTime dateTime = DateTime.now().addDays(-1);
     return [SELECT id FROM Contact WHERE CreatedDate < : dateTime];
}
[/code]

В тестах этот метод ничего не вернёт, но можно ведь сделать так:

[code]
public static List<Contact> getOldContacts(DateTime dateTime){
     return [SELECT id FROM Contact WHERE CreatedDate < : dateTime];
}
[/code]

Куда более универсальный метод, не так ли?)

Проблемы тестирования возникают из-за сильной связанности кода.
Всем DRY

Gres

Проблемы тестирования возникают из-за сильной связанности кода.
Всем DRY

Дима Лисовский

Быть может стоит метод переделать, избавиться в нём от зависимости, передав дату в аргумент.

"Переделать" для моего случая точно не вариант. Код у меня и так покрывается за счет других условий. Хотелось записать "человеческие" тесты чтобы воссоздать реальную ситуацию. Но получается проще забить на этот use case чтобы не ломать красивый код

Получается вот такой большой камень в огород sf.

Dmitry Shnyrev

[quote="Дима Лисовский"]Быть может стоит метод переделать, избавиться в нём от зависимости, передав дату в аргумент.[/quote]

"Переделать" для моего случая :) точно не вариант. Код у меня и так покрывается за счет других условий. Хотелось записать "человеческие" тесты чтобы воссоздать реальную ситуацию. Но получается проще забить на этот use case чтобы не ломать красивый код :) 

Получается вот такой большой камень в огород sf.