CodeScience tech webinars offer useful tips and tricks from members of our industry-leading engineering teams. In our latest webinar, Lead Salesforce Developer Bobby Tamburrino shared his perspective on testing data and strategies ISVs can use to improve product development lifecycles.
For our recent webinar, Bobby leveraged his 20 plus years of experience as a software engineer to explain first why test data is so important for product development and common pitfalls with test data. Then he discusses the common methods ISVs can implement to build better performing products and evaluates their pros and cons.
Defining Test Data
The first step for understanding the impacts of test data on a product dev cycle is to understand what’s meant by the phrase “test data.” As Bobby notes, test data is a series of records that indicate what live data might look like once a product is released and in users’ hands. Each of these records needs to be vetted by a subject matter expert to ensure they make sense for the use case.
“Test data also represents a smaller subset of data that can be rapidly loaded into new environments,” adds Bobby. “Each record should also have relationships with other records to illustrate the future data model.”
It’s also essential to understand what test data is not — copies of production instances with user-created data, data unrelated to the product use, and data intended for Apex Unit Tests. As Bobby suggests, “Keep it [test data] simple. Keep it close to what you’re going to be building in the near future.”
Paying attention to test data organization can make it easier for QA to complete regression testing, DevOps can more quickly spin up orgs with relevant data, and developers can build against realistic data without having to build the data sets themselves. As such, test data should be defined when new objects are created and as features and test cases evolve or are deprecated.
Why is this important? As you may guess, accurate test data enables accurate testing. Bobby highlights that without properly accounting for the realistic nature of the data being tested (relationships with other records), you can inadvertently pass along an application that fails once it gets production data loaded in.
A Closer Look at Loading Methods
After covering the basics of test data, Bobby dives into methods for loading test data, including data loader, bulk API, and SalesforceDX Data Tree Import and Export.
Having covered the advantages and disadvantages of using SalesforceDX Data Tree, Bobby jumps into a demo to show how the tool works for loading test data. SalesforceDX Data Tree represents the newest solution covered in Bobby’s overview, showing that Salesforce is making progress in terms of addressing loading test data. However, as Bobby’s demo illustrates, leveraging Data Tree for complex data sets presents some challenges and limitations, such as a 200 record limit.
So what’s the best solution? Turns out, building a custom tool can deliver the functionality necessary for proper test data loading. For the second demo in the webinar, Bobby walks viewers through the custom test data loader we affectionately call LoadScience here at CodeScience to associate all records and data correctly.
Closing Words
Bobby closes his webinar by sharing a few pieces of wisdom regarding test data.
“Identifying test data early and iterating on it as testing continues can be a lifesaver for QA and developers,” he says. “But keep in mind that complex relationships and data sets may ultimately require a custom solution that should be budgeted into estimates.”
Want to learn more and see the demos in action? Check out the webinar today!
Do more with your Salesforce product than you ever thought possible. At CodeScience, we enable ISVs to thrive on the AppExchange. Learn how we can help your business today.
