Регистрация  |  Вход

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

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


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; }
}

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


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# писали ?

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

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

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

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

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

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

Ну и как по мне название класса 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);

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

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

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

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

сделал так:

        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;

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

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

String name = sp.name;

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

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

String name = sp.name;

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

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

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

String name = sp.name;[/quote]

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

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

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

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

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

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

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

[quote="Dmitry Lisovsky"]Гетеры/Сеттеры (проперти) только для использования в экспрешенах visualforce {!obj.prop}.[/quote]
Да и для этого в 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);

[quote="Dmitry Shnyrev"][quote="Dmitry Lisovsky"]Гетеры/Сеттеры (проперти) только для использования в экспрешенах visualforce {!obj.prop}.[/quote]
Да и для этого в 90% случаем достаточно просто написать.

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

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

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

есть метод 

    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;}

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

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

[quote="Dmitry Shnyrev"][quote="Dmitry Lisovsky"]Гетеры/Сеттеры (проперти) только для использования в экспрешенах visualforce {!obj.prop}.[/quote]
Да и для этого в 90% случаем достаточно просто написать.

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

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

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

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

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

К примеру

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

[quote="cool"]данные приходят с VF page , как тестируется ?[/quote]
Тебе надо инстанс контроллера, проинициализировать переменные которые должны придти из страницы и просто вызвать метод.

К примеру

[code]PageController p = new PageController()
p.inputPrice = 100;
...
p.addProduct()
system.assert ...[/code]

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


catch(Exception e){

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

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


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.
В этом случае можно точнее воспроизвести проверки и воссоздать ситуацию с невалидными данными внутри тестов.

Ну обычно Эксепшепы я покрываю только в исключительных случаях. А точнее практически никогда.
Для этого и предусмотрено необходимый минимум 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;
}

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

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


 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 приложение и посмотри как там реализовывают операцию удаления.

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

[quote="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; 
} [/quote]

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

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

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

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

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

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

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

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

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

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

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