Is there a better way to create related records when creating test data?

Question

I am trying to create a large set of test data along with child records and this is what i came up with. Could anyone let me know if there's a better way to achieve the same?

Integer countStart = 1800;
Integer countEnd = countStart+999;    
List<Account> masterAccs = new List<Account>();
    List<Account> businessAccs = new List<Account>();
        for(integer i=countStart; i<=countEnd; i++){
            Account a = new Account(Name = 'License '+i, 
                                   Account_Type__c = 'Master Business');
            masterAccs.add(a);
        }
        try{
            Database.SaveResult[] result = database.insert(masterAccs);
        }
        catch(exception e){
            system.debug('Master Exception: '+e.getMessage());
        }

        Id AccRecordTypeId = Schema.SObjectType.Account.getRecordTypeInfosByName().get('Business Location').getRecordTypeId();

        for (Account a : masterAccs){
            for(Integer j=countStart;j<=countEnd;j++){
                //String sj = String.valueOf(j);
                if(a.Name.Contains(String.valueOf(j))){
                    Account ba = new Account(Name = 'License Jr '+j,
                                             RecordTypeId = AccRecordTypeId,
                                             Master_Account__c = a.Id,
                                             Account_Type__c = 'Business Location');
                    businessAccs.add(ba);
                }
            }
        }
        try{
            Database.SaveResult[] result = database.insert(businessAccs);
        }
        catch(exception e){
            system.debug('Business Exception: '+e.getMessage());
        }

        List<Request__c> reqs = new List<Request__c>();
        for (Account b : businessAccs){
            for(Integer j=countStart;j<=countEnd;j++){
                if(b.Name.Contains(String.valueOf(j))){
                    Request__c req = new Request__c(Account_Name__c = b.Id,
                                                    Status__c = 'Pending',
                                                    Type__c = 'License Application',
                                                    Received_Date__c = System.today());
                    reqs.add(req);
                }
            }
        }
        try{
            Database.SaveResult[] result = database.insert(reqs);
        }
        catch(exception e){
            system.debug('Request Exception: '+e.getMessage());
        }
        List<License__c> createLics = new List<License__c>();
        List<Request__c> reqsU = [SELECT Id, Account_Name__r.Name FROM Request__c WHERE Account_Name__r.Name LIKE '%License Jr%'];

         for (Request__c r : reqsU){
            for (Integer j=countStart;j<=countEnd;j++){
                if(r.Account_Name__r.Name.Contains(String.valueOf(j))){
                    License__c l = new License__c(Licensee__c = r.Account_Name__r.Id,
                                                 Request__c=r.Id);
                    createLics.add(l);
                }
            }
        }
        try{
            Database.SaveResult[] result = database.insert(createLics);
        }
        catch(exception e){
            system.debug('License Exception: '+e.getMessage());
        }

Answer 1

Everywhere you have this structure:

for (Account a : masterAccs){
    for(Integer j=countStart;j<=countEnd;j++){
        if(a.Name.Contains(String.valueOf(j))){
            // create child record
        }
    }
}

You can instead simply index into your List<Account> and reduce the number of statements made to create this child data by a factor of 1000.

for (Integer countStart; i <= countEnd; i++)
{
    parent = masterAccs[i];
    // create child record
}

The same simplification can be made where the parent collection is businessAccs, reqsU, etc.

The other major change you should make is remove your try/catch blocks. An empty catch block (and debug statements do not count as non-empty) is borderline malignant programming and "technical debt" is not a strong enough term for how bad this code is for the stability of your org. You are silently swallowing errors, which will complicate deployments, automated test runs, etc. Your code will not fail where it should, and instead you will get confusing messages which are often quite difficult to track down and fix.