I know this topic has been surfaced many times in conversion in our team and I am sure the same is happening in your team. Let me say it " AUTOMATED TESTING"!!!
I am on a small but mighty team in which we spend a lot of time testing our own code or regression testing upgrades. We would like to have easier way (i.e. automated) to handle these tasks.
Is anyone having success using a solution for these testing needs?
If so, what are you using ?
1 Like
Would love to see feedback from other IIQ clients on this topic!!!
@Mathew_Cantrell @patrick_daniels - any internal SailPoint contacts that could weigh in on this topic? I’m sure there is a lot of interest among other IIQ clients. Perhaps this was covered in an office hours segment or other forum?
If not, we would surely welcome this as a special topic!
Christine
Hi @CMA11 , we usually give Developer Community posts a few weeks before bringing in out internal teams to answer questions directly! Let’s give this one some time for the community to answer and then we can discuss further! Thank you!
1 Like
Sure thing! Wasn’t sure if you were aware of any existing reference materials or previous sessions where this may have already been addressed.
Bumping the thread!
Any IIQ clients have input here?
We’ve been slowly moving away from the SailPointJUnitTestHelper and towards using JUnit5 with Spring Boot annotations to only setup specific slices of the application as necessary. This lets you easily mock, trace, and inject various things like giving you the ability to use an in memory database for testing that gets created, populated, and destroyed after each test.
If you’re just unit testing beanshell rules, you don’t even need an in memory database. Instead, we set up a FilePersistenceManager that loads all of the local xml configs into a JUnit @TempDir that hibernate can still read and write from, so things like context.getObjectByName() work without configuring and starting an actual db context of any kind. Very useful for unit testing beanshell rules quickly.
We also started using Playwright for user experience testing. It allows you to test and record UI interactions in a web browser in an automated way.
We also use PMD for static code analysis, Checkstyle for linting, switched our build process over to use Gradle instead of Ant, and are working on creating rules for a beanshell parser to allow for more automated checking of that without relying on regex patterns.
2 Likes
Dalton, one of things that takes us a lot of time is Data Setup. Most of the time we need to ensure the Test User has this set of Application Accounts, Roles or Entitlements, or just this set of attributes from Workday (Workday ones are easy) prior to testing our custom code.
Are you using JUnit5 with Spring Boot or something else for this.
It really varies based on what exactly we’re testing.
For most tests, we don’t need full blown Identities and all the object relations that implies. Most just need something small like a Identity identity = new Identity(); identity.setName("TestId"); that you can either use directly or have Mockito return whenever something like context.getObjectByName(Identity.class, "TestId"); is called. Or a ResourceObject that you create and pass to a correlation rule that was loaded using a FilePersistenceManager and BeanShell parser with no other objects involved.
If you need something more, we’ve had luck using JUnit Custom Aggregators to bulk create objects for testing in a standardized way.
If you want everything backed by an actual database Database Initialization :: Spring Boot has a lot of options. The simplest is probably just telling spring boot where to find your create_identityiq_tables-x.x.sql file and then creating another data.sql file that creates the actual base objects you care about, but you might want to just create the schema and then create objects for each test and use the built in Transaction Management to clean up after.
For UI testing, Parameterize tests | Playwright is what we use to set everything up consistently.
So yeah. Lots of options all with various pros and cons depending on what you’re going for. I generally mentioned them in order of speed, fastest to slowest, since that’s a big priority for testing locally. But we also have various stages in our CI/CD pipeline that run different kinds of tests with varying data load requirements based on what they’re targeting, so you don’t have to just pick one way to do it all.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.