помогите с тестами кто -нибудь плиз

помогите с тестами кто -нибудь плиз

дайте наводку как тестируется такой класс

public class Products{

private Product__c pr;
public Products(Product__c item) {
this.pr = item;
}
public String name {
get { return pr.Name__c; }
}
public Decimal price{
get { return pr.Price__c; }
}
public Decimal quantity{
get { return pr.Quantity__c; }
}
public String type{
get { return pr.Type__c; }
}
public Date date_add{
get { return pr.Date__c; }
}
public Date date_delete{
get { return pr.Release_Date__c;}
}
public Boolean availability{
get { return pr.Availability__c; }
set { pr.Availability__c = value; }
}

Вы наверное до этого на C# писали ?

Такой класс тестируется очень просто.
В тесте создается инстанс класса и просто дергаются все атрибуты.

Но вообще то что я вижу в примере выше сильно далеко от того что принято в SF. Проще говоря никто так не кодит. Хотя любители ООП без такой вермишели прожить не могут. Поэтому соглашусь с Сергеем, вы явно откуда-то из другого мира

Ну и как по мне название класса Products явно намекает на то что там должны храниться более одного продукта, а по коду видно что это обертка для одного продукта.

Dmitry Shnyrev
Такой класс тестируется очень просто.
В тесте создается инстанс класса и просто дергаются все атрибуты.

Но вообще то что я вижу в примере выше сильно далеко от того что принято в SF. Проще говоря никто так не кодит. Хотя любители ООП без такой вермишели прожить не могут. Поэтому соглашусь с Сергеем, вы явно откуда-то из другого мира

Ну и как по мне название класса Products явно намекает на то что там должны храниться более одного продукта, а по коду видно что это обертка для одного продукта.

сделал так:

Product__c pr = new Product__c(Name__c = 'Ts', Price__c = 3, Quantity__c = 4, Type__c = 'cloth', Date__c = Date.newInstance(2008, 1, 1), Release_Date__c = Date.newInstance(2008, 1, 30), Availability__c = true);
MyController.ShowProducts sp = new MyController.ShowProducts(pr);

sp.pr.Name__c = 'Ts';
sp.pr.Price__c = 3;
sp.pr.Quantity__c = 4;
sp.pr.Type__c = 'cloth';
sp.pr.Date__c = Date.newInstance(2008, 1, 1);
sp.pr.Release_Date__c = Date.newInstance(2008, 1, 30);
sp.pr.Availability__c = true;

System.assert(pr.Name__c == 'Ts');
System.assert(pr.Price__c == 3);
System.assert(pr.Quantity__c == 4);
System.assert(pr.Type__c == 'cloth');
System.assert(pr.Date__c == Date.newInstance(2008, 1, 1));
System.assert(pr.Release_Date__c == Date.newInstance(2008, 1, 30));
System.assert(pr.Availability__c == true);

и выходит что теститься только конструктор, а остальное не идет, как быть ?

Не тестится потому что ты напрямую читаешь поля из pr переменной
А методы не задействуешь

Попробуй вставить в тест строку

String name = sp.name;

Dmitry Shnyrev
Не тестится потому что ты напрямую читаешь поля из pr переменной
А методы не задействуешь

Попробуй вставить в тест строку

String name = sp.name;

Вот кстати и отличный пример что у тебя в исходном классе хрень написана. Все эти куча геттеров нафиг не нужны. Сам же их и не используешь. Нафига тогда ты их туда навставлял?

Гетеры/Сеттеры (проперти) только для использования в экспрешенах visualforce {!obj.prop}. Иначе используй поля класса.

Dmitry Lisovsky
Гетеры/Сеттеры (проперти) только для использования в экспрешенах visualforce {!obj.prop}.

Да и для этого в 90% случаем достаточно просто написать.

public String someVar1 {get; set;}
public Integer someVar2 {get; set;}
public Boolean someVar3 {get; set;}

Когда дело дойдет до более сложных геттеров, то вопросов про как писать тесты уже будут даааалеко позади.

Dmitry Shnyrev
Dmitry Lisovsky
Гетеры/Сеттеры (проперти) только для использования в экспрешенах visualforce {!obj.prop}.

Да и для этого в 90% случаем достаточно просто написать.

public String someVar1 {get; set;}
public Integer someVar2 {get; set;}
public Boolean someVar3 {get; set;}

Когда дело дойдет до более сложных геттеров, то вопросов про как писать тесты уже будут даааалеко позади.

я понял? еще вопрос

есть метод

public void addProduct() {
try{

Product__c m = new Product__c(
Name__c=inputName,
Price__c=inputPrice,
Quantity__c=inputQuantity,
Type__c=inputType,
Date__c=inputDate,
Release_Date__c= inputReleaseDate
);
insert m;

}

catch(Exception e){
ApexPages.Message myMsg = new ApexPages.Message(ApexPages.Severity.FATAL,'Incorrect data input');
ApexPages.addMessage(myMsg);
}
}

данные приходят с VF page , как тестируется ?


catch(Exception e){

ApexPages.Message myMsg = new ApexPages.Message(ApexPages.Severity.FATAL,'Incorrect data input');
ApexPages.addMessage(myMsg);

Dmitry Shnyrev
Dmitry Lisovsky
Гетеры/Сеттеры (проперти) только для использования в экспрешенах visualforce {!obj.prop}.

Да и для этого в 90% случаем достаточно просто написать.

public String someVar1 {get; set;}
public Integer someVar2 {get; set;}
public Boolean someVar3 {get; set;}

Когда дело дойдет до более сложных геттеров, то вопросов про как писать тесты уже будут даааалеко позади.

спасибо большое))

cool
данные приходят с VF page , как тестируется ?

Тебе надо инстанс контроллера, проинициализировать переменные которые должны придти из страницы и просто вызвать метод.

К примеру

PageController p = new PageController()

p.inputPrice = 100;
...
p.addProduct()
system.assert ...

это я сделал, я про вот этот кусок

catch(Exception e){

ApexPages.Message myMsg = new ApexPages.Message(ApexPages.Severity.FATAL,'Incorrect data input');
ApexPages.addMessage(myMsg);

Ну обычно Эксепшепы я покрываю только в исключительных случаях. А точнее практически никогда.
Для этого и предусмотрено необходимый минимум 75%. Остальные 25% можно оставить непокрытыми. Собственно в них и входят все эти мелкие блоки в catch.

Вообще в твоем примере смысла в try/catch нет.
Если надо проверить пользовательские данные это надо делать руками, точнее с помощью if/else.
В этом случае можно точнее воспроизвести проверки и воссоздать ситуацию с невалидными данными внутри тестов.

Dmitry Shnyrev
Ну обычно Эксепшепы я покрываю только в исключительных случаях. А точнее практически никогда.
Для этого и предусмотрено необходимый минимум 75%. Остальные 25% можно оставить непокрытыми. Собственно в них и входят все эти мелкие блоки в catch.

Вообще в твоем примере смысла в try/catch нет.
Если надо проверить пользовательские данные это надо делать руками, точнее с помощью if/else.
В этом случае можно точнее воспроизвести проверки и воссоздать ситуацию с невалидными данными внутри тестов.

public void deleteProduct(){
for(Product__c pr : [SELECT Name__c, Price__c, Quantity__c, Type__c, Date__c, Release_Date__c, Availability__c FROM Product__c ]){
if(inputNameDel.equals(pr.Name__c)){
delete pr;
}

static testMethod void deleteProductTest()
{
test.startTest();
Product__c pr = new Product__c(Name__c = 'Ts', Price__c = 3, Quantity__c = 4,Type__c = 'cloth', Date__c = Date.newInstance(2008, 1, 1), Release_Date__c = Date.newInstance(2008, 1, 30),Availability__c = true);
insert pr;
MyController controller = new MyController();
controller.inputNameDel = 'Ts';
controller.deleteProduct();
System.assertEquals(pr.IsDeleted, true);
test.stopTest();
}

что не так в этом тесте?

как протестить удаление,а именно вот эти 2строчки
if(inputNameDel.equals(pr.Name__c)){
delete pr;
}

cool
public void deleteProduct(){
for(Product__c pr : [SELECT Name__c, Price__c, Quantity__c, Type__c, Date__c, Release_Date__c, Availability__c FROM Product__c ]){
if(inputNameDel.equals(pr.Name__c)){
delete pr;
}

ЧТО???? Это кто так учил код писать?
Это просто звиздец! Такое не только в SF нельзя писать, но вообще нигде!!!
Найди в нете любое простейшее СRUD приложение и посмотри как там реализовывают операцию удаления.

Когда исправишь этот код, тогда поймешь как его протестировать.

вот что выдает Assertion Failed: Expected: false, Actual: true

cool, я советую немного отойти назад и оставить тесты.
Начни изучение с начала. Не знаю как сейчас в Trailhead но раньше были доступны Workbooks для изучения (их можно найти в нете). Просто выключи мозги и сделай все что там написано прям по шагам.
Потому что с таким кодом лучше на собеседованиях не появляться, карму сольешь себе навсегда.

Dmitry Shnyrev
cool, я советую немного отойти назад и оставить тесты.
Начни изучение с начала. Не знаю как сейчас в Trailhead но раньше были доступны Workbooks для изучения (их можно найти в нете). Просто выключи мозги и сделай все что там написано прям по шагам.
Потому что с таким кодом лучше на собеседованиях не появляться, карму сольешь себе навсегда.

спасибо за совет:)

cool, лучше пройди trailhead https://trailhead.salesforce.com/trails/force_com_dev_beginner , пройдя его, сможешь легко понять почему метод "deleteProduct()" написан плохо.

Interesting information? Help us, post link to social media..