Testing is a major challenge in building and deploying applications that are responsive to changing business and user needs. Pega applications often contain hundreds if not thousands of rules, so managing a test suite that is aligned with business goals becomes paramount for successful continuous integration and continuous delivery approaches. You want to ensure that the rules in your Pega Platform applications perform as expected and do not introduce errors that may propagate through the application and interrupt or break critical business functionality. The tests you run on rules should calibrate to business goals and user expectations of quality.
Many business technologists who build Pega Platform applications outside of enterprise IT rely on testing to ensure their applications reliably serve their respective business needs. This group of business users is a crucial partner in both the application development and testing processes. Either working alone or in a co-production model alongside Pega certified system architects, senior system architects, and lead system architects, building rules and building tests for those rules should occur simultaneously, regardless of the role or team composition. The practice of building an entire application or a large chunk of one first, then testing it, stifles overall development time and increases time to market in an enterprise setting. Similarly, it keeps your departmental or team application from being deployed in both a timely and complete manner. Keeping an accurate, running record of which application components are covered by tests is likewise critical to ensure maximum functionality with minimal work duplication.
Fortunately, Pega Platform makes it easy to both build-and-test rules near simultaneously and keep a real-time record of which rules are covered by tests. Pega Platform’s test coverage tool shows how many rules are covered by the various tests in your application and which rules still need test coverage. It displays a dashboard of helpful data that allows developers to quickly access rules without test coverage and build tests for them such as unit tests and scenario tests. You can improve your application quality by building tests for all uncovered rules indicated by the test coverage tool.
With the right tools, the developer is freed to think more reflectively on the rules they build and the tests that cover them.
Building for reflective practice
How developers perceive the act of application testing is a key aspect in learning to build for testing. Is it a series of procedures to simply test rules or could we consider testing as a way of thinking about how we’re building the application’s rules? Taking the simultaneous build-and-test approach affords valuable opportunity to reflect on both how you are building rules for testing and how potential tests may, in turn, influence rule design.
As you design rules, consider how they can be easily tested. As you test, consider how the rule that you are testing affects functionality and user experience. These are moments to cultivate a reflective practitioner mindset. As you build rules with testing in mind and test with the rules themselves in mind, you can reflect on the decisions made for both and consider improvements to efficiency, security, and flexibility. Being a reflective practitioner means keeping your audience and purpose central to your work and allows you to re-evaluate decisioning in terms of the business and user goals.
Consider the benefits of a simultaneous build-and-test process as a reflective practitioner in terms of developing two key types of awareness:
When you consider how the rules and their tests could influence each other, you are thinking towards which strategies are important in implementing a particular rule or test. Examine the function of the rule itself: is this particular rule the most efficient, reusable, and appropriate way to perform the task you need to address in the application?
For example, are you building a rule that helps customers decide on product options? Then you may design a test that ensures the rule returns the expected number of product options when it is run. Likewise, are you building a test for rule execution time? Then you may consider how your rule could minimize time making calls to external data sources.
These strategies should then be discussed, made explicit, and be reused to fit similar rule-building and testing situations. This further reduces development and testing time while increasing application quality standards.
Reflecting on strategies for rule-test interactions can only take you so far. It is equally important to reflect on when, why, and how to execute those strategies. This type of awareness is concerned with how to apply rule-building and testing strategies to drive goals and get the outcomes you need.
As you reflect on the business and user goals, such as reducing processing time and more securely connecting sensitive data, you can discern certain rule-building and testing strategies over others. Situational, appropriate, and timely decisions for both rule-building and testing can be made based on your understanding of how an audience's needs interact with the application’s purpose and constraints.
Similarly, this decisioning should be discussed and made explicit so that others can align on a more consistent building-and-testing practice.
Openly and honestly reflecting on the implicit decisions we make when we develop or test rules helps not only to improve the overall processes and reduce time for developing and testing rules, but also to bolster working together as a cohesive team. When groups reflect on how they build and test rules together, they create an active community of practice from which focused, timely, and flexible strategies emerge.
- Learn more in Pega Academy about rules and rule types
- Learn more in Pega Academy about crucial testing approaches
- Learn more in Pega Academy about how to test rules using Unit Tests and Scenario Tests