Збільшити тестове покриття для класу TourNameTriggerHandler.

[ViktorNosenko]

Наразі клас покритий тестами на 75%. Задача підвищити покриття до максимально можливої межі.

[ViktorNosenko]

На даний момент тест TourNameHandlerTest написаний некоректно.

Потрібно переробити тести згідно до умов нижче: 1) Тести повинні перевірити як буде працювати код при вставці/оновленні багатьох записів одночасно. 2) Тести повинні явно показувати яка саме логіка перевіряється. Як приклад тестовий метод з назвою testInsertTours. В ньому ми повинні перевірити що при одночасній вставці записів Tour імена для всіх цих записів будуть оновлені корректно. Але наразі просто витягуємо з БД запис і перевіряємо постфактум значення в полі Name.

Нижче наведено один з можливих варіантів як це можна реалізувати.

    @testSetup 
    static void setup() {
        // Підготовка данних для тестування
    insert generateCustomObjects();
    }

    static List<CustomObject__c> generateCustomObjects() { 
        // Логіка для генерації потрібних для тестування записів
    }

    static List<CustomObject__c> getCustomObjects(){
        // Логіка для отримання з БД записів потрібних для тестування
    }

    @isTest 
    static void testUpdateNameLogicForCustomObjects() { 

        // Підготувати потрібні данні
        List<CustomObject__c> testObjects = getCustomObjects();

        // Виконати перевірки данних якщо це потрібно.
        // Також перевірка данних на цьому етапі явно покаже іншим розробникам початковий стан данних
        for(CustomObject__c customObject : testObjects){
            System.assertEquals('OldName', customObject.Name);
        }

        Test.startTest();
        // Виконання DML операції або виклик методу що тестується
        update testObjects;
        Test.stopTest();

        // Перевірка результатів
        for(CustomObject__c customObject: testObjects){
            System.assertEquals('NewName', customObject.Name);
        }
    }

P.S. Якщо використати інший контекст виконання тригера ми зможемо обійтись без лишньої DML операції. Перед зміною в тестах варто подумати про оптимізацію логіки в тригері.

[ViktorNosenko]

Вже набагато краще але все ще є моменти для покращення.

1) Тестовий метод testInsertLogicForTours все ще потребує доопрацювання згідно з паттерном описаним вище. 2) Метод з аннотацією @testSetup використовується для генерації тестових данних. Щоб максимально оптимізувати тести потрібно перенести вставку всіх можливих тестових данних в цей метод. 3) Що буде в випадку коли ми змінемо ім'я для туру? Чи хендлимо ми цей сценарій взагалі? 4) Чи можемо ми покращити методи generateCustomTours() та getCustomTours()?